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Abe  -trac  t 


In  recent  yearSf  axioa  systeaia  for  the  verif  icat 
concurrent  alftorithms  have  been  developed*  A  set  ot  con 
processes  Is  suitably  represented  by  a  concurrent  stateee 
variables  shared  between  processes  are  represented  by  a 
data  objects* 

This  thesis  sumnarizes  different  forsats  of  con 
statements  and  shared  abstract  data  types,  fo 
representation  of  concurrency  with  varylnpt  deRre 
granularity*  Previously  proposed  axiomatic  requireae 
their  semantics  are  interrelated,  and  new  axioms.  In  par 
for  the  manager  data  type  for  dynamic  resource  allocati 
formulated*  Partial  correctness  as  well  as  termination  a 
subject  of  investigation* 


Strengths  and  weaknesses  of  the  discussed  language  f 
and  axiom  systems  are  illustrated  by  comparing 
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^  In  tr  o<t  action 


With  the  ri Bi ns  nuaber  ot  software  tooisy  the  verification 
of  concurrent  algorithna  has  received  a  laris®  amount  of 
attention  in  recent  years*  Hoars  was  one  of  the  first  to  point 
out  the  need  for  a  formal  proof  technique  particularly  for 
concurrent  aleori  thns  (Hoa72a]*  Time-dependent  errors  caused  by 
the  concurrent,  (interleaving  or  parallel)  execution  of 
processes  are  an  additional  unreliability  factor,  which  does  not 
apply  for  sequential  programs,  and  which  is  especially  difficult 
to  grasp* 


Conceptually,  there  are  two  different  approaches  to  verify 
concurrent  systems,  on  the  basis  of  [Flo67]: 

a)  The  processes,  the  sequential  units  of  the  concurrent 
program,  are  first  verified  sequentially  without 

consideration  of  their  concurrent  environment*  Secondly,  the 
assertions  made  in  the  sequential  proofs  at  different  points 
of  process  execution  are  shown  to  be  preserved  by  every 
possible  concurrent  execution  of  the  processes,  a  property 
which  has  been  called  non-interference  (OwGr76a,  DwGr76b3* 


This  approach  emphasizes  the  system  structur 
collection  of  sequential  processes*  Such  a  vi 
concurrent  programs  supports  basic  principles  of  s 
design!  information  hiding  and  modularity  [Par72]* 
conteaporary  concurrent  programming  langtmges  d 
algorithms  as  a  collection  of  processes,  proofs 
carried  out  at  the  text  level  of  the  source  program* 

Owicki  and  Lamport  (see  references  in  chapter  6) 
this  approach*  Owicki  uses  Hoare* a  method  of  outl 
proof  by  inserting  assertions  about  the  state  of  the 
variables  into  the  program  text  [Hoa69]* 


e  a  s  a 
ew  of 
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Because 
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can  be 
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program 


b)  Rather  than  formulating  assertions  about  the  execution  of 
sequential  processes,  the  concurrent  execution  of  the  entire 
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pros^ram  is  described*  First  the  proB***^*  has  to  be 

transformed  into  a  representation  that  suits  reri fi cat 1 ony 

usually  a  flow  graph  model •  One  can  view  each  node  of  the 

graph  as  some  state  of  concurrent  execution  and  each  directed 
edge  as  a  transformation  of  one  state  into  another*  (Keller 
introduces  a  bipartite  graph  instead  (Kel76l*)  Assertions 
are  associated  with  nodes;  they  describe  the  program  state  of 
every  concurrent  execution  when  it  passes  through  that  nodey 
if  it  does  so* 

This  technique  does  not  hare  to  contain  a 

non-interference  argument y  because  the  execution  of  the 

entire  program  is  described*  (For  multiprocessor  systems 
Interference  problems  may  arlsey  though*) 

Tn  both  approachesy  following  [Fio67]y  the  constraints  in  a 
program  specification  are  expressed  by  initial  assertions  and 
its  goals  by  final  assertions*  Intermediate  assertions 
associated  with  different  states  of  execution  of  the  prograsy 
regardless  of  whether  they  are  attached  to  statements  in  the 
source  texty  to  nodes  in  a  flow  graphy  or  to  something  else  in  a 
different  modely  will  outline  the  transformation  of  the  initial 
into  the  final  assertion  by  every  execution  of  the  program*  The 
state  transformations  are  only  valid  under  the  assumption  that 
the  transforming  actions  terminate  (so-called  partial 

correctness)*  Termination  isy  in  generaiy  argued  separately* 

In  this  theslsy  we  shall  only  look  at  Owlcki's  approachy 
the  process— by— process  verification  of  concurrent  algorithms  by 
interleaved  program  assertions*  The  notation 


iipn  s 

MR  If 

expresses  that 

f 

under 

the  assumption 

P  immediately  before 

t  he 

execution  of  statement  Sy 

R  wi  11 

ho  Id 

immediately  after 

i  ts 

t  ermi nat 1  on • 

P 

is  called  the 

precondition  (pre(S))y  R 

the 

postcondl t ion 

( post ( S) ) 

of  S* 

The 

statement  S  ••R” 

is 

referred  to  as 

a 

proof  or 

y  if  axlomaticy 

proof  rule  for  S* 

(The 
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specia.1  character  ”  mtiy  be  Interpreted  as  a  consent  del  ini  ter* 
In  the  literature  braces  are  usedf  (P)  S  (R)  t  but  ve  need  then 
for  set  denotation* ) 

Sometimes  the  change  of  a  variable  state  by  a  statement  is 
described  explicitly  by  dvnmy  vaiueSf  such  as 

»»x=cw  S  «x=f(c)” 

Another  notation  is  to  express  a  variable's  output  state 
directly  by  its  Input  state! 

«pre(S)  »*  S  "x'  =  f  (x)  •* 

X*  refers  to  x  after  the  execution  of  S* 


Abstracting  completely  from  executiont  S  can  be  vleved  ns  a 
predicate  transformer  mapping  P  onto  R*  Analogously f  knowing  S 
and  R*  one  can  derive  the  weakest  precondition  P=wp(S,R)  such 
that  S  "R”  (see  (DIJ761)*  In  [C;ri76]f  Srles  points  out  the 

significance  of  pre—  and  postconditions  for  program 

specification  and  argues  that  deriving  weakest  preconditions 
from  postconditions  and  statements  aids  in  program  development* 

The  tool  for  the  solution  of  a  programming  problem  is  the 
set  of  language  featuresy  the  programming  language  one  decides 
to  use*  The  basis  for  the  verification  of  the  program  is  a 
c  orre  spondl  ng  set  of  axiomatic  proof  rules  for  those  language 
features*  They  define  the  semantics  of  the  languagey  and  the 
language  implementor  has  to  make  sure  that  all  axiomatic 
requirements  are  met*  The  user  then  may  assume  their  validity 
without  argument*  An  example  for  the  axiomatic  definition  of  a 
language  is  [Howi73]y  which  defines  Pascal*  All  popular 
sequential  statements  used  in  the  following  will  comply  to  the 
semantics  of  Pascal* 

The  rule  for  the  assignment  statement  isy  for  instance! 


»*P  ”  X  :=  R  wp" 

E 

X 

where  P  is  the  assertion  formed  by  replacing  every 

E 


free 
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nccurrence  of  x  in  P  by  Ef  for  exxaple 


"x+l>y»  X  :=  x+1  «x>y*« 


In  the  case  of  the  assifcnaent  stateaent  terninatlon  is  trivial: 
It  may  always  be  expected  to  teminatey  presusinK  the  expression 
F  Is  leffal*  For  other  statesents  that  perform  iterationsy  for 
instancey  termination  Is  more  complex*  Frecfuently  the  partial 
correctness  and  termination  behaviour  of  a  laneuaite  feature  are 
axioniatlzed  separatelyy  but  a  sinsle  axiom  may  also  comprise 
both  aspects*  We  shall  introduce  a  formalism  later* 

Important  for  the  successive  deduction  of  assertions 
between  statements  is  the  rule  of  consequence! 

tipin  s  "R*  "y  P=>P«  y  B«=>H 
npii  s  ttpH 

a 

Roth  ~  and  a=>b  mean  a  Implies  b*  Whereas  the  implication 
h 

denoted  by  the  rlsHt  arrow  has  to  be  proveny  the  horizontal  bar 
expresses  an  axiomatic  implication  that  holds  by  definitiony  if 
the  presumpt iony  the  upper  operandy  is  valid*  (In  the 

literature!  for  =>  often  K  or  o  are  used*) 


The  addition  of  concurrency  to  a  lansuaite  complicates 
verification*  At  this  pointy  we  shall  not  look  at  particular 
specifications  of  concurrency  but  only  discuss  the  problem  of 
verifying  statements  thaty  in  some  fashiony  are  specified  to 
execute  concurrently* 


After  the  derivation  of  proof  rules  for  each  of  the 
concurrent  statements  from  assertions  about  their  sequential 
contextsy  non-interference  must  be  proven  additionally:  For  each 
statementy  its  execution  may  not  affect  any  assertion  made  in 
the  proofs  of  other  statements  that  execute  concurrently*  More 
forma  1 ly : 
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Let  S  and  T  be  stateaents  conctirrent  to  each  other*  and  let 
the  proof  for  S  be  **P**  S  "R**#  -Then  T  does  not  interfere  with 
the  proof  of  S  iff 

i  )  »»RApre(  T)  "  T 

ii)  For  any  stateaent  S*  contained  in  S 
**pre(  S*  )  Apr  e(  T)  "  T  ”pre(S*)" 

A  set  of  statements  concurrent  to  each  other  Is  called 
I n ter f erence— f r ee  iff  no  elementary  action  in  any  of  them 
Interferes  with  the  proof  of  any  other  statement  in  the  set« 

Elementary  actions  are  those  that  can  safely  be  treated  as 
i nd i V is ib 1 e • 

Interference  must  only  be  considered  in  the  case  of 
concurrency*  To  avoid  interference  problems  in  particular 
program  parts*  one  may  want  to  define  statements  as  elementary* 
The  notation  is 


[  S]  ; 

where  S  is  the  statement  to  be  elementary*  For.  Intermediate 
assertions  in  S*  non-interference  is  an  axiomafic  requirement 
and  need  not  be  proven* 

Elementary  actions  are  offen  less  appropriately  called 
indivisible  or  atomic*  The  requirement  that  achieves 

non-interference  is  that*  with  respect  to  accesses  to  shared 
variables*  the  elementary  statement  acts  like  an  indivisible 
statement*  However*  it  need  not  be  indivisible  regarding 
accesses  to  other  data* 

To  interrelate  the  progress  of  concurrent  processes*  one 
often  has  to  enrich  the  algorithm  by  additional  variables* 
Owicki  calls  them  auxiliary  variables*  They  keep  t  ractc  of  the 
processes*  sequential  execution  histories*  The  treatment  of 
auxiliary  variables  may  not  affect  the  flow  of  control  or  data 
1  n  the  rest  of  the  program*  More  formally! 
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X  la  called  an  auxiliary  variable  iff  x  appears  in  fhe 
program  only  in  asaiannen't  atateaenta  of  the  fora  x:  =  Ef  where 
the  expression  E  aay  contain  any  auxiliary  or  prodraa 
variable# 

An  auxiliary  variable  axiom  states  that  the  proof  of  an 
aldorlthn  with  auxiliary  vairiables  also  holds  for  its 
implementation  without  auxiliary  variables  tOwGr76af  OwGr76b]« 

The  following  two  chapters  build  the  fraaework  for  this 
thesis  with  a  discussion  of  recent  approaches  to  the 
specification  of  concurrency  and  rules  for  its  verification* 

Chapter  2  deals  with  shared  abstract  data  types  that 
provide  different  grains  of  concurrency  for  the  access  to  their 
data*  Shared  abstract  data  types  are  an  iaportant  aid  in  the 
communication  of  their  concurrent  accessors*  The  types 
investigated  here  are  monitors  [lloa74]f  managers  [SKB7719 
classes  synchronized  by  path  expressions  [PlHa76]t  and  general 
shared  classes  COwi77b]*  Proof  rules  for  partial  correctness 
are  given*  If  previously  developed*  Termination  of  calls  to 
shared  abstract  data  objects  is  discussed  thoroxighly  In 
chapter  4* 

Chapter  3  is  concerned  with  the  specification  and 
verification  of  concurrent  processes*  A  representation  suitable 
for  verification*  the  concurrent  statement*  is  motivated  and 
defined  in  different  forms*  Proof  rules  for  partial  correctness 
and  termination  are  given* 

Chapter  4  is  the  core  of  the  thesis*  The  tools  previously 
described  are  compared  In  two  applications!  a  concurrent  system 
synchronized  by  a  semaphore  and  a  system  using  a  pool  of 
resources*  After  correlating  different  verification  techniques 
and  motivating  their  necessity*  new  proof  rules  are  developed! 
partial  correctness  axioms  for  the  abstract  data  type  mana ger 
and  termination  axioms  for  calls  to  shared  abstract  data 
objects*  in  general* 
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The  thesis  ends  with  soMe  conclusions  about  the  usefulness 
of  the  exhibited  concepts  and  with  sufCKsatlons  for  further 
research* 
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2  Shared  Abatract  Data  Type a 

The  concept  of  abstract  data  typaSf  which  first  attracted 
attention  In  SIMULA  CDaHo72]f  has  In  recent  years  received  such 
consl derat ion t  due  to  its  eaphasla  on  aodularlty  and  resource 
protection*  It  is  a  wery  iaportant  structurlns  factor  in 
proi^ranai nfft  especially  operating  system  deeiffn* 

An  abstract  data  type  defines  a  data  atrxicture  by  a  set  of 
variable  dec lar at  ions f  and  all  operations  on  them  by  a  set  of 
procedures*  An  initial  statement  determines  the  state  of  the 
data  before  their  use*  A  data  object  of  some  abstract  data  type 
comprises  an  incarnation  of  the  variables  declared  In  the  data 
type  and  access  rights  to  it  via  the  operations  defined  In  the 
data  typey  by  procedure  calls  of  the  fora 

objec tnaae*  procnamef  parameters)  ; 

The  data  are  protected  from  any  access  of  a  different  kind* 
e*4;*9  direct  assignment* 

Two  of  the  many  advantages  of  this  concept  become 
particularly  evident  in  this  thesis: 

a)  Information  Hiding 

A  programmer  using  an  object  of  some  abstract  data  type 
does  not  have  to  worry  about  implementation  details 
concerning  its  access*  Only  the  semantics  of  the  data  type 
operations  have  to  be  understood* 

Following  [Hoa72b]9  we  shall  distinguish  the 

specifications  A  of  some  abstract  data  typey  which  state  the 
semantic  propertlesy  and  its  concrete  implementation  7y  which 
achieves  these  properties* 

The  specifications  contain  the  following  statements: 
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Peq ( 4  )  • 


Ini t (  4)  : 
1(4): 


states  presumptions  for  parameters  of  the 
abstract  data  t^jrpe  f 

states  the  initial  properties  of  the  lataf 
states  an  invariant  assertion  that 
characterizes  the  data  between  accessest 


Operations:  ••• 

op  (parameters) 
i 


pre:  states  the  presumptions  for  correct 

functioning  of  op  y 

i 

post:  states  the  result  of  op  y  assuming 

i 

op  Apre  is  fulfilled  at  its  executiony 
i 


[LiZiTS]  discusses  several  specification  technicrues  f  3  r  data 
abstract  ions* 


To  verify  the  correct  implementation  of  an  abstract  data 
typey  a  napping  will  often  be  needed  that  associates  the 
abstract  object  4y  characterized  by  the  specif icationsy  with 
the  concrete  object  Cy  characterized  by  the  Impi emen ta t i on* 
We  call  this  mapping  the  abstraction  function 


4  =  F(C) 


For  the  correctness  of  the  concrete  object  then  the  following 
have  to  hold: 


1*)  1(C)  =>  1(4) 

2*)  ”Req(4)”  Initial  statement  **I  nl  t  (  4)  aI  (  C )  *• 

1* )  For  each  operation  op ( var  x;  y) 

"op*  pre  (xyyy4)Al  (C)" 
body  of  procedure  op 
"op*post(xyyy4) AT(C) " 
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where  x  ia  a  wee  ♦or  ot  war!  able  paraixeteret 

and  y  ia  a  vector  of  constant  (value)  parameters* 


In  the  case  that  operations  are  allowed  to  execute 
concurrently  on  the  same  data  object  Xf  the  call  of  an 
operation  op  also  needs  special  proof  rulesf  since  the 
expected  rule 


*»P"  X.op(a«e)  "R" 


where 


_  X  y  caller 

P  5  X*op«pre_  _ 

a  e  1 

_  *  y  caller 

R  ~  Y«op«poat_  _ 

a  e  1 

may  not  be  Interf e renc e— f ree •  To  prove  non— in terf erence f  one 
has  to  take  the  environment  of  the  caller  Into  account* 
Owlckl  suKRests  an  **adaption'*  axiom  (Owl77at  Owl77b]: 


whe  re 


and 


•*P"  X*op(a,e)  wpn 

»*v(Pa  _a_  R=>Q)  «  X.opiaye)  "0” 

£  a*  z( cal 1 er ) 

a  coaprlses  the  actual  variable  paraaeters* 

e  comprises  the  actual  value  parametersy 

ic  comprises  the  variables  free  In  P  and  Ry 

hut  not  Oy  ay  and  ey 
Py  R  as  abovey 

z(caller)  is  the  list  of  variables  changed  by  op* 


Ve  only  state  this  result  for  the  sake  of  completeness  and 
shall  not  elaborate  on  it  any  further* 

b)  Stepwise  Verification 


The  abstract  data  type  supports  a  bottom-up  verification 
of  the  prog*'»m« 


If  one  postulates  that  ainy  two  abstract  data  objects  aiay 
not  access  each  other  in  turny  directly  or  Indirectly 
( forward— r ef or end ng) y  abstract  data  objects  can  be  organized 
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in  an  access  hierarchy  of  the  follovlng  fors  CLen77]: 

1*  Level  0  Is  the  set  of  data  objects  that  do  not  access 
any  other  data  object* 

2*  Level  1  contains  all  abstract  data  objects  X  with  the 
propert i es : 

I)  there  exists  a  data  object  on  level  1-1  which  is 
accessed  by  X* 

II)  all  data  objects  accessed  by  X  are  on  levels  Jt 
such  that  J<1* 

This  hierarchy  can  be  imposed  on  the  set  of  abstract  data 
typeSf  because  all  objects  of  the  same  type  must  bel  oni^  to 
the  same  hierarchy  level*  The  significance  of  hierarchies 
for  prosiram  structuring  has  been  recognized  in  [Par74)* 

One  can  prove  the  correctness  of  an  access  hierarchy  by 
successive  verification  of  Its  levels  0*  If  2f  etc*  In 
particular f  changes  in  level  1  can  affect  the  correctness  of 
only  levels  J  such  that  J> i J  in  other  words!  once  verifiedf 
the  core  of  the  hierarchy  will  be  correct*  in  whatever 
environment  it  is  implemented* 

We  will  be  looking  at  shared  data  types*  l*e**  data  types  whose 
objects  may  be  required  for  access  by  several  processes* 
possibly  concurrently*  The  main  difference  from  private  data 
types  is  that  the  consistency  of  the  shared  data*  expressed  by 
the  invariant  assertion  for  the  data  type*  has  to  be  maintained 
by  a  proper  synchronization  of  the  accesses  to  them*  The 
distinguished  shared  data  types  we  shall  look  at  differ  mainly 
in  their  means  of  synchronizing  accesses* 

The  verification  of  shared  abstract  data  types  has  to 
contain  an  argument  for  proper  synchronization  as  well  as 
non-interference*  Note  that  an  operation  may  also  interfere 
with  itself*  when  several  processes  execute  it  concurrently* 
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Sync  hron  izl  ni?  accesBefl  to  Rhareti  daiba  objects  creates  the 
possibility  of  deadlock  In  access  hierarchies  for  some  types* 
This  matter  will  be  mentioned  but  not  covered  by  axioms*  For 
proof  rul es f  we  assume  that  a  shared  data  object  does  not  access 
any  other  shared  data  object  in  its  operations* 


2*1  Wonl tors 

The  shared  abstract  data  type  that  has  first  been 
formulated  and  implemented  and  that  is  today  most  popular  is  the 
monitor  fHoa74]*  Its  synchronization  scheme  has  two  levels! 

i )  short-term  scheduling 

ensures  thaf  the  monitor  procedures  are  executed  mutually 
exclusive  to  each  other*  It  is  part  of  the  lan^uape  and  not 
influenced  by  the  programmer* 

i  i  )  medium— term  schedul  i  ng 

is  the  synchronization  of  processes  in  accordance  with  the 
state  of  the  monitor  data*  It  has  to  be  defined  by  the 
designer  of  the  monitor*  The  tool  provided  by  the  language 
Is  a  condition  data  type*  Variables  of  type  condltl  on  may 
only  be  declared  local  to  a  monitor  object  and  represent 
waiting  queues  of  accessors  of  that  object*  with  no  further 
specified  scheduling  policy*  They  are  initially  enpty  and 
manipulated  by  way  of  two  standard  procedures! 

If  cond  is  a  condition  crueue* 

cond.walt;  suspends  the  caller*  adds  it  to  the  queue 

cond*  and  releases  the  monitor  for  further 


access* 
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cond*  s  i  snai;  if  any*  process  is  vaifinff  in  condy  suspends 

the  caller  and  grants  access  to  the  process  in 
cond  with  highest  priority*  We  shall  only 
axiotnatize  and  discuss  this  signalling 
algoritha*  For  different  policies  see 
[ How76b ] • 

The  use  of  scheduling  operations  during  a  son i tor  access 
Introduces  the  problem  of  deadlock  in  an  access  hierarchy  of 
monitors*  Sayy  monitor  A  accesses  monitor  By  and  processes  do 
not  access  B  direct lyy  but  only  through  A*  If  then  some  process 
is  being  delayed  inside  a  procedure  of  A  because  of  medium-term 
scheduling  in  By  it  blocks  access  to  Ay  which  disables  others  to 
enter  B  and  to  establish  the  resumption  condition*  The  process 
is  blocked  indef i ni te ly y  and  A  as  well  as  B  are  inaccessible* 
An  example  for  such  a  case  in  a  resource  management  system  is 
sketched  in  [SKB77];  another  in  a  message  switching  system  is 
described  in  [ Len77 ] • 

As  a  consequencey  monitor  hierarchies  are  not  desirable* 
But  there  are  other  shared  data  types  that  allow  at  least  a 
restricted  use  of  access  hierarchies* 

To  verify  synchronization  in  monltorsy  we  define  the 
following  partial  correctness  axioms  for  wait  and  signal  from 
[ Owi77a] : 

"PaT(C)’*  cond*  wait  ••Pa  I  (  C)  aB  (  c  ond )  " 

•'PaI  (C)  aB(  cond)  ••  cond.signal  ♦•PaKC)** 

Hcrey  B( cond )  represents  the  resumption  condition  for  processes 
that  are  waiting  in  condy  and  P  contains  only  parametersy  local 
variablesy  or  constants  free*  C  names  the  implementation  of  the 
monitor  that  contains  cond*  The  appearance  of  1(0  in  the  rules 
for  wait  and  signal  Indicates  that  the  scheduling  operations  do 
not  affect  shared  data;  the  appearance  of  P  says  that  they  do 
not  affect  local  data*  Only  the  condition  queue  is  Involved* 
The  invariant  has  to  be  valid  at  times  of  schedulingy  because  it 
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wrlli  hold  wh«nciver  the  acoeeeor  of  the  monitor  la  switched* 


Several  different  suffice  s  tl  on  s  have  been 
proof  rules*  Others  will  he  outlined 
chapter  4* 


made  for  monl tor 
and  discussed  In 


2  •  2  Maaaiie£a 


The  concept  of 
ISKI177]*  A  manatirr  la 
dynanlc  allocation  of 
abstract  data  tyne  to 
the  special  processes 


a  manaiiEMr  has  recently 
a  shared  abstract  dat 
objects  of  some  other  (p 
processes*  It  Is  not  to 
that  are  called  nanacfers 


been  proposed  in 
a  type  for  the 
rlvate  or  shared) 
be  confused  with 
In  ( JaSt77 1* 


The  managrer  has  exactly  the  sane  synchronization  scheme  as 
the  monitort  but  does  not  completely  protect  all  of  the  data 
specified  in  It*  One  declaration  in  the  manaicer  is  the  pool  of 
a  11  oca  table  resourcesy  e*  ft*  y 


var  pool:  a£raZ.  Indexset  Qf  resource; 

The  data  type  of  the  nllncatable  objects  is  determined  by  the 
header  of  the  manager  definition: 


'  nanattername  s  SfiQSfig!!  Hl  capability:  resource; 

Processes  define  an  access  rlitht  to  the  resource  pool  by 
declar  Intr 

var  object!  resource  fcoffi  ma  nag;ername ; 

Access  rights  to  the  nianafter  itself  are  never  specified* 

The  access  r  iaht  to  a  resource  object  established  by  the 
above  declaration  is  not  fixed  for  the  entire  execution  t imey  as 
it  would  be  i  f  no  manager  were  invoivedy  but  only  temporarily* 
The  manafycer  distributes  the  temporary  access  rlgchts  (so-called 
capabilities)  amona  processes  that  require  themy  and  this  may 
Involve  sync  hron  Izat  1  on*  For  an  easier  Implementation  and 
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V  erl  f  Icat  lont  the  restriction  is  made  that  every  process  may  be 
granted  at  most  one  access  right  by  a  manager  object  at  a  time! 
In  other  vordsy  no  process  may  hold  sore  than  one  object  troia  a 
fixed  resource  pool*  An  implicit  parameter  declared  In  the 
header  of  the  manager  deflnitlony  here  with  name  capxbilityf 
holds  the  current  access  right  (if  any)  of  the  process  that  is 
preforming  the  manager  call* 

The  binding  of  capabilities  to  processes  is  performed  by 
two  standard  procedures  which  are  used  in  manager  operations! 

blnd(r);  grants  the  caller  a  capability  to  resource  object  r* 
release;  withdraws  the  caller's  current  capability* 

The  manager  resolves  the  deadlock  problem  with  access 
hierarchies  for  two-level  hierarchlesy  as  described  In  [SKB77]: 
Replace  the  monitors  In  the  higher  leveiy  that  are  In  danger  of 
blockingy  by  a  manager*  In  a  hierarchy  that  is  not  a  tree 
(where  the  lower  level  means  the  leaves) y  the  replacement  mayy 
however*  lead  to  some  loss  of  modular  structure*  Multi— level 
hierarchies  remain  problematlcy  but  are  probably  rare  In 
appllcatl ons  * 

For  the  verification  of  managers*  we  need  additional  axioms 
for  the  binding  operations*  They  have  not  been  proposed  in 
previous  publications  and  will  be  formulated  In  chapter  4* 
together  with  a  detailed  description  of  the  semantics  of  bind 
and  release* 


2  •  ^  Rxpress  Ion  Cl  asse s 

rCaHa74*  FlHa76j  suggest  defining  the  concurrency  permitted 
among  operations  on  an  abstract  data  object  by  a  single 
exoression  associated  with  the  data  type!  Its  path  expression* 
The  operands  in  the  path  expression  are  the  data  type's 
procedures,  and  several  operators  relate  their  executions  to 
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each  other! 

i  )  sequence!  opl  ;  op2 

opl  and  op2  arc  executed  conaecut ive ly f  opl  only  before 
op2t  op2  only  after  opl* 

ii)  selection!  oplt  op2 

Fither  opl  or  op2  Is  executedf  but  not  neither  nor  both* 

n 

111)  repetition!  (op) 

op  Is  executed  repeatedly«  n  times  in  sequence*  If  n  is 
omlttedf  op  Is  executed  indefinitely* 

Iv)  simultaneous  execution!  (op} 

op  may  be  executed  concurrently  to  itself  untilf  at  some 
timet  no  process  Is  executins  op*  Then  no  subsequent  call 
to  op  will  be  executed* 

More  complex  Is  the 

n 

v)  restricted  repetitive  selection!  (opltop2) 

A  sequence  of  calls  to  opl  or  op2  is  executedf  preserving 
the  assertion 

0  <  #  (opl )  t  #(  op2)  S  n 

#(op)  is  the  number  of  times  op  has  been  executed  on  the 
data  object  since  Its  Initialization* 

The  path  expression  is  In  the  implementation  of  an  abstract  data 
tyoe  denoted  by 

£ath  expression  end; 

The  expression  may  he  evaluated  repeatedlyt  i*e*t  path*  *  *  end  has 
the  same  semantics  as  (***)*  As  an  example«  the  expression 

path  (read)  $  write  end; 


denotes  the  synchronization  of  concurrent  readers  and  writers 


on 
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shared  data:  Readers  Majr  access  the  data  concurrently  as  long  as 
there  la  no  writing  access;  a  writer  needs  exclusive  access* 

Path  expressions  are  a  very  high-level  and  somewhat 
restricted  synchronization  concept*  Synchronization  does  not 
take  place  inside  the  operationsy  but  rather  the  calls  to  data 
type  procedures  are  synchron  i  zedy  much  In  the  spirit  of  the 
w i t  h- when  statement  for  the  specification  of  conditional 
critical  sections  t Hoa72a  1*  This  may  cause  a  loss  of  scheduling 
f I exi bi 11 ty * 


s 

P 

s 

O 

e 

P 

t 

e 

c 

d 

d 

a 

c 

s 


On  the  other  handy  path 
hort— terra  and  medium-term 
rogrammery  and  thereby  intr 
chedullng  scheme  than  Is 
perations  are  not  in  anir  cas 
xecuted  concurrently  as  Ion 
reserved*  Howevery  because 
o  synchron! zat i on y  either 
xclusive  with  an  entire  oper 
oncurrent  to  each  other* 


The  feature  of  optional 
eadlocked  access  hlerarchi 
escribed  in  section  2*1  can 
eri t  of  path  expressions  is 
oncurrent  execution  and 
ynchronl zat 1  on* 


expressions  merge  the  defini 
schedulingy  leaving  both 
od\ice  a  more  general  sho 
provided  by  monitors  and  ma 
e  mutually  exclusive  y  but 
g  as  the  consistency  of  the 
the  calls  of  operations  are 
an  entire  operation  opl  is  a 
at  ion  op2y  or  both  are  e 

concurrency  may  help  to 
es*  But  cases  such  as 
still  be  unpreven tab  1  e*  The 
the  useful  combination  of  ef 
structured  speciflcatlo 


tion  of 
to  t  he 
rt-  te  rm 
nagers* 
may  be 
data  is 
sub J  ec  t 
utua I ly 
n tl re ly 


a  vol  d 
the  one 
ma  J  or 
f  1  c 1 en t 
n  of 


Tn  proof Sy  for  every  statement  in  some  class  procedurey 
non-interference  with  the  procedures  concurrent  to  It  has  to  be 
shown*  The  pre—  and  post-conditions  of  any  procedure  need  not 
be  in terf erence— f ree  In  the  proof  of  the  abstract  data  typey  but 
the  according  assertions  for  the  call  of  the  procedure  must  be 
i  nt  er  f  erenc  e- f  ree  In  the  calling  process  (see  the  introduction 
to  this  chapter)  *  As  another  consequence  of  concurrencyy  an 
additional  requirement  for  the  sequential  correctness  of 


not 


18 


completely  exclusive  operations  iSf  that  the  class  invariant 
must  be  valid  between  any  two  elementary  actions  ot  the 
procedure*  More  formally: 

Let  op  be  a  procedure  of  class  C  that  is  concurrent  to  some 
operation  of  C*  Then  for  all  elementary  actions  A  in  opf 

pre ( A )  =>  1(C) 

has  to  hold* 


2*4  Genegg:!  Shar  ed  C_lags  eg 

[Owi77b]  defines  the  most  general  form  of  shared  abstract 
data  tyneSf  the  general  shared  class* 

Synchronization  takes  place  inside  the  class  operations* 
and  any  statement  in  some  operation  may  be  made  mutually 
exclusive  or  concurrent  with  any  other  statement  or  itself*  As 
a  synchr on i zat ion  tool*  condition  queues  are  conceivable*  but 
Owlckl  chooses  an  in  terms  of  scheduling  decisions  slightly 
higher— level  concept*  the  semaphore*  As  with  path  expressions* 
both  short—  and  tnedlunt- term  scheduling  are  the  responsibility  of 
the  class  programmer* 

Proof  rules  are  needed  for  the  semaphore  operations* 
(Owi77b]  does  not  state  any*  we  will  discuss  them  in  chaoter  4* 

To  simplify  verification*  Owlcki  requires  the  body  of  class 
procedures  to  have  the  format 

begi  n  declarations;  enter;  operate;  exit  end; 


w  here 


i)  enter  and  exit  are  elementary  actions  or  null  statements* 
and  operate  is  composed  of  elementary  actions* 
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ii)  the  vari&bles  accesned  by  enter  and  exit  are  called 
control  variables;  those  accessed  by  operate*  data 
variables*  A  variable  local  to  a  class  way  not  be  both 
control  and  data  variable* 


above  structure  for  class  procedures  Is  a 

affected  by  the  operation  Into 
nchronlza tlon*  and  data  variables 
lass  object  as  it  is  perceived  by 
rol  variables  should  not  appear 
for  the  class  operations  and  the 
the  class  Invariant*  Since  enter 
postulation  Is  not  really  a 
ovever*  that  a  synchronization 
ons  (like  the  path  expression)  Is 


The  effect  of  the 
seoaration  of  the  variables 
control  variables  that  guide  sy 
that  define  the  state  of  the  c 
the  caller*  Consequently*  cont 
In  pre—  and  postconditions 
initial  statement*  but  only  in 
and  exit  can  be  null*  this 
restriction*  It  indicates*  h 
scheme  that  frames  the  operati 
In  general  easier  to  verify* 

The  proof  rules  for  shared 
expression  classes* 


classes  are  the  same  as  for  path 
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3  The  Concurrent  S tetepient 


In  the  last  decadey  several  representations  of  cone 
have  been  suggested  (Brl73]»  Restricting  ourselves 
structured  syntaK  merely  leaves  us  with  two  choices! 

a)  Process  Modules 

Processes  are  represented  as  self-contained 
comprising  data  and  actlonSf  much  in  the  sense  of  a 
data  types*  Execution  of  a  process  object  may  be  caus 
special  start  statement* 

This  approach  is  a  structured  formulation  of  th 
statement  from  [Con63]  and  is  implemented  in  Con 
Pascal  [Bri7S]*  Concurrent  execution  of  several  proce 
siiccess  1  ve  ly  initiated  hy  forking  the  path  of  cont 
start  statements  on  different  process  objects  into 
parallel  paths* 

The  structured  concurrent  extension  to  PL/l# 
[KGLS781,  works  in  a  similar  manner*  Here»  all  proces 
Imnlirltly  started  after  program  initialization* 

b)  The  Concurrent  Statement 


[Con63]  also  Introduces  a  J.oi_n  statement  f  dual  to 
which  relates  the  time  of  termination  of  some  process 
state  of  execution  of  other  concurrent  processes*  Wit 
onlyt  one  cannot  determine  when  a  process  has  term 
The  structured  notation  is 

c  ob  eg  i  n  S 1  / /S2/ /•**// Sn  coend; 

where  c  ob  e  g  i  n  refers  to  a  "multi”  — fork  and  coend 
"mu  1  1 1 JLoi_n  of  n  processes  SI*  Concurrent  execution 
Si  begins  at  the  point  of  co^gi^n  and  ends  at  coend*  w 
Si  have  terminated*  Kesting  of  concurrent  states 
legal  and  in  particular  useful  for  statements  aho 
termination  of  a  subset  of  m  concurrent  processes^  m<n 


urre  nc  y 
to  a 


modu 1 es 
bs  tr  act 
ed  b  y  a 

e  f  ork 
curr  en t 
sses  i  8 
ro 1  via 
se  ve  ra  1 

eSP/k 
ses  are 


fork* 
to  t  he 
h  f  ork 
Inat  ed* 


to  a 
o  f  the 
hen  all 
ents  is 
ut  t  he 
• 
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For  ver 1 f ica t 1 ont  the  concurrent  atateaent  is  the  aore  usetul 
choiccf  becauae  it  peroiita  the  formulation  of  an  aaaertlon  about 
the  proftrani  state  after  the  termination  of  aoae  concurrent 
processt  In  the  form  of  a  postcondition  for  a  concurrent 
statement*  Without  a  Join  of  parallel  execution  paths*  ve  would 
not  know  at  which  point  in  the  proijram  that  assertion  holds* 

Three  formats  of  concurrent  statements  appear  in  the  literature! 


a)  The  general  concurrent  statement  t OwGr76a ] 


does  not  protect  shared  variables  by  a  special  data 
structure*  Its  synchronization  primitive  is  the  await 

s ta  tene  nt • 

b)  The  concurrent  statement  with  resource  (Hoa72at  OwGr7Sb] 

specifies  shared  data  in  a  resource  declaration  which 
protects  them  automatically  from  accesses  that  cause 
Incons istency t  but  does  not  associate  the  data  with  the 
operations  on  them*  Its  primitive  for  sync hron Izat ion  and 
access  of  shared  data  is  the  w it h~when  statement* 

c)  The  concurrent  statement  with  abstract  data  types  [Owi77a] 

provides  full  protection  and*  moreover*  hides  matters  of 
synchronization  in  the  abstract  data  types* 

We  will  not  look  closer  at  the  concurrent  statement  with 
resource*  It  is  merely  a  predecessor  of  the  concurrent 

statement  with  abstract  data  types  and  has  the  same  capabilities 
in  expressing  concurrency*  if  in  the  latter  abstract  data  types 
are  used  that  do  not  permit  concurrent  execution  of  their 
operations  (monitors  or  managers)* 

The  general  concurrent  statement  is  more  powerful  *_  Shared 
data  may  be  accessed  in  non~elemen tary  actions  as  in  the 
concurrent  statement  with  abstract  data  types  which  permit 
concurrent  execution  of  their  operations  (path  expression 
classes  or  general  shared  classes)* 
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3*1  The  General  Cone  urre  n't  Sta'teaent 


As  described  beforof  the  general  concurrent  statement  has 
t  he  form : 


c^beg^n  Si / /S2 //•••/ /Sn  coondj 

Variables  declared  outside  the  statement  are  fi^lobal  to  all  Slf 
those  declared  inside  are  local  to  the  process  that  contains  the 
declaration*  For  slmpllcityt  the  laneuaii[e  has  no  procedures* 
Fxacution  of  the  concurrent  statement  terminates  vhen  all 
processes  SI  hare  terminated* 


We  need  not  require  any  assumptions  about  the 
Indivisibility  of  statements  In  the  Si  it  the  follorine 
convention  is  obeyed! 

Fach  expression  E  may  reter  to  at  most  one  variable  y  which 
can  be  chanuzed  by  another  process  during  the  evaluation  of  E« 
and  E  may  refer  to  y  at  most  once*  The  same  restriction  is 
required  for  assignment  statements  x!=E* 


Then»  only  memory  reference  has  to  be  indivisible*  Note  that 
assignments  of  the  form 

X  :=  f  (x)  ; 

refer  to  x  several  times  as  well  as  assignments  to  data 
structures,  svich  as 


A  :  =  b; 

for  arrays  A  and  B*  Such  statements  do  not  follow  the  previous 
convention  and  have  to  be  specified  elementary  if  they  are 
desired  as  such! 

[A  :=  B] ; 


The  await  statement  provides  the  synchronization  tool  for  the 
concurrent  access  of  shared  variables*  The  general  format  is 

await  B  [S]; 
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where  [S]  denotes  an  elessntary  stateasnt  that  is  executed  onljr 
if  B  is  true*  If  B  is  falset  the  process  execatlns  aw ai t  Is 
delayed  and  continues  with  (S]  when  B  becomes  true*  It  is 
assumed  that  awai t  performs  fair  scheduiins;  more  specif ical ly» 
the  process  executing  ^wa^^t  is  delayed  only  until  B  becomes 
true*  S  may  not  contain  a  concurrent  statement  or  another 
awai 1 1  to  avoid  deadlock  problems  caused  by  nested  awa its  (as 
with  hierarchies  of  shared  abstract  data  types)* 

r>wicki*s  proof  rules  for  the  seneral  concurrent  statement  are 

n 

A  ”Pl»*  Si  ”Ri  ”  in  ter  f  erence— f  ree 
1  =  1 


*•  A  Pi  ••  cobesin  Sl//***//Sn  coend  •*  a  R1»* 
i=l  ~  i=l 

"PaB"  S  "R»* 

and  - - — - 

"P**  tXaLl  B  [S]  »»R« 

where  the  sequential  proofs  for  the  processes  t  ”P1”  Si  "Ri***  are 
1  nter f erence— free  iff  for  ail  i  every  stateaKnt  In  Si  does  not 
interfere  with  the  assertions  in  the  proofs  of  all  SJf  J^l* 
(For  the  definition  of  '^does  not  interfere  with"  see  chapter  1*) 
IOwGr76a]  points  out  that  one  can  reduce  the  non-interference 
test  to  awai t  statements  and  assignment  statements  outside 
a wa its*  Ail  other  statements  are  elementary  and  therefore 
trivially  interf  e  renc  e- f  ree  • 


3*2  The  Concu rre  n t  S  ta  tement  w i^t h  Abstract  Data  Types 

For  many  appl icat ions*  especially  in  operating  systems*  it 
will  not  be  necessary  to  manipulate  data  shared  by  concurrent 
processes  before  their  execution*  In  this  case*  the  effect  of 
the  concurrent  statement  is  clarified  if  all  shared  data  are 
defined  as  m  abstract  data  objects  associated  with  it: 

shared  Cl  :  Tl  *  *  *  *  *  Cm:  Tm  cobeg^n  Sl//***//Sn  coend  ; 
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The  firet  action  ot  the  concurrent  stateaent  1b  to  Initialize 
all  shared  objects  and  thereby  create  the  Initial  enrlronaent 
for  all  processes*  Since  the  synchronization  Is  part  of  the 
abstract  data  type  operations^  no  specific  sync  hroa  Izat  Ion 
primitive  need  be  defined  for  this  form  of  concurrent  statement* 

Let  us  make  the  restriction  that  the  concurrent  statements 
we  Look  at  may  have  only  the  followinfi  combinations  of  shared 
abstract  data  types: 

a)  monitors  or  manaccers 

b)  path  expression  classes  or  general  shared  classes 

This  Is  only  for  demonstration  purposes*  We  shall  demonstrate 
that  exclusive  shared  abstract  data  types  are  easier  to  handle 
than  those  that  permit  concurrency* 

A  more  severe  restriction  is  that  ve  do  not  allow 
hierarchies  of  shared  data  types*  With  the  exception  of  the 
resource  type  In  managers f  no  access  right  may  exi  st  between 
different  shared  data  objects*  Therefore  the  proof  rules 
Introduced  In  chapter  2  suffice* 

Owickl  defines  the  partial  correctness  axiom  for  the 
concurrent  statement  with  abstract  data  typeSf  according  to  the 
previous  semantic  description: 

n 

A  •*?!**  SI  •’Hi”  1  nt  er  f  erenc  e~  f  ree 
1  =  1 

*•(  A  Tnit(CJ  ))  =>  (  A  Pi  )« 

J=l  1=1 

shared  Cl :  T 1 1  *  *  *  f  Cm :  Tn  cobegl^n  Sl//***//Sn  coend; 

"{  A  I(  C  J)  )  A  (  A  Ri  )H 

J=1  1=1 

Ffere»  non-interference  means 

i )  for  concurrent  statements  with  monitors  or  managers: 

For  shared  abstract  data  types  with  only  mutually  exclusive 
uperationsf  the  requirement  Is  that  the  PI  and  R1  are  safe« 
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i«e*y  <to  not  refer  to  variables  that  are  chancted  in  several 
processes  (In  analogy  to  the  concurrent  statenent  with 
resource).  Theny  Interference  in  the  original  sense  (see 
chapter  1)  cannot  occurt  because  such  variables  are  only 
manipulated  in  elementary  actions* 

11)  for  concurrent  statements  with  path  expression  classes  or 
general  shared  classes: 

For  shared  abstract  data  types  that  allow  concurrent 
execution  of  their  operationsy  the  usual  non-interference  is 
required  (in  analogy  to  the  general  concurrent  statement)* 
Howevery  the  only  statements  that  can  Interfere  are  calls  to 
operations  of  shared  abstract  data  types;  other  statements 
cannot  access  shared  data* 

Ve  emphasize  again  that  the  above  semantics  define  a  quite 
restrictive  concurrent  statementy  in  the  sense  that  no 
computation  carried  out  before  its  execution  has  any  relevance 
for  it*  More  relaxed  semantics  as  expressed  by  the  axiom 

n 

A  ”P  i'*  Si  ”Ri**  i  nter  f  erence— fr ee 
1=1 

"(  A  KCJ))  A  (  A  Pl)»* 

J=1  i=l 

sha  red  Cl : T1 y • • * y Cm! Tm  cobegin  Sl//***//Sn  coend; 

"(  A  I(CJ))  A  {  A  Rl)»» 

J=1  1=1 

are  conceivable  and  will  often  be  necessary  in  appl ic at  ions y 
where  a  concurrent  computation  is  merely  part  of  a  larger 
sequential  context*  In  this  casey  the  shared  data  objects 
belong  to  the  environment  surrounding  the  concurrent  statement 
rather  than  the  concurrent  statement  itseify  and  they  have  to  be 
initialized  and  may  be  manipulated  before  its  execution* 

This  thesis  will  only  use  the  former  semantics*  We  are 
interested  in  the  mere  structure  of  concurrent  computations* 
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^ ^  Terml nalt  1  on  of  Coocurren  t  Stgteaeots 

Proof  rules  ^iven  so  far  In  fhla  thesis  only  refer  to 
partial  correctness*  For  the  terailnation  argumentf  a  set  of 
termination  axioms  has  to  be  cteflnedf  or  the  partial  correctness 
axioms  have  to  be  extended  to  cover  termination* 

The  termination  rules  described  here  are  taken  from 
[OwGr76al*  After  the  proof  of  sequential  termination  of  the 
processes  specified  in  the  concurrent  statementf  it  has  to  be 
shown  that  termination  is  not  affected  by  their  concurrent 
execution*  Thereforef  the  definition  of  non-interference  (see 
chapter  1 )  has  to  be  extended  by  non-interference  with 
t  erra i na t i on  • 

A  common  practice  to  argjue  termination  is  to  define  a 
function  on  a  well-founded  setf  a  set  that  is  ordered  in  such  a 
way  that  no  infinite  decreasing  sequences  of  elements  exist 
[MaWa78]f  for  instance  the  positive  IntegerSf  and  to  show  that 
the  alfitorlthra  decreases  this  function  successively*  Then  it 
must  reach  a  lower  bound  In  a  finite  time  and  terminate*  Hencef 
the  additional  requirement  for  a  statement  T  not  to  Interfere 
with  the  proof  of  a  concurrent  statement  S  can  be  formulated! 

lii)  Given  a  proof  for  S  that  uses  a  termination  function  t* 
T  does  not  Interfere  with  the  termination  proof  of  S  iff 

”t=c  A  pre(T)»  T  «t<c'» 

c  is  a  dummy  value  as  described  in  chapter  1* 

A  set  of  statements  concurrent  to  each  other  is  then  called 
J  nter  ference-f  ree  iff  no  elementary  action  In  any  of  them 
interferes  with  the  partial  correctness  or  termination  proof  of 
any  other  statement  In  the  set* 

If  the  above  non-interference  is  establlshedf  processes  may 
still  be  held  up  by  indefinite  blocking  caused  through 
synchronization.  Proof  rules  dealing  with  this  problem  are  more 
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complex  anilf  of  c  oursey  rtepend  on  the  synchronization  scheme 
used*  For  the  a5rai_t  in  general  concurrent  statenentsy  [DwGr76a] 
proves  the  following  criterioni 

Let  S  be  a  statement  whose  partial  correctness  rule  is 
iipii  3  '’R”,  Let  the  a  wal  t  s  of  S  that  arc  not  contained  in 
concurrent  statements  of  S  be 

A  *  awai t  B  [ • • • ] 

J  J 

Let  the  concurrent  statements  of  S  which  are  not  part  of 
other  concurrent  statements  of  S  be 

k  k 

T  :  cob«gl.‘l  S  //•••//S  c  oend ; 

k  In 

De  f  I  ne 

0(3)  E  [v(pre(A  ) a^B  ]  v  (v{d  (T  )] 

J  J  J  k  1  k 

k  k  k 

n  (T  )  £  CA(post(S  )VD(S  ))  ]  A  [VD(S  )] 

1  k  i  i  i  i  i 

Then  -»D(S)  implies  that  no  execution  of  S  can  be  blocked 

1 n  def i n i t  e ly • 

The  proof  uses  Induction  on  the  nesting  levei  of  concurrent 

statements*  D( S )  is  a  recursive  characterization  of  blocking* 

If  the  first  term  of  D(S)  is  t rue y  S  is  held  up  at  some 

statement  A  •  D  (T  )  says  that  some  process  in  the  concurrent 

J  I  k 

statement  T  is  blocked  despite  the  fact  that  all  others  have 

k 

t  erm I na  ted • 

Tn  the  case  of  the  concurrent  statement  with  abstract  data 
typesy  absence  of  Indefinite  blocking  means  that  all  calls  to 
shared  abstract  data  type  operations  terminate*  This  matter 
will  be  discussed  in  chapter  4* 

The  combined  partial  correctness  and  termination  axiom  for 
any  format  of  the  concurrent  statement  is 
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n 

A  •*?!"  SI  "Rl**  I  nterferenc*— ^ree  a 
1  =  1 
n 

A  Si  cannot  he  blociced  indefinitely 
1  =  1 


”P**  concurrent  statement  of  Slf**«fSn  **R** 


whore  non-interference  and  P  and  R  are  defined  for  the  different 
formats  as  in  the  sections  3»1»  3«2« 
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^  The  Feasibl 11 ty  of  Verification  Cone epta 

We  shall  now  try  to  evaluate  the  sisnificance  and 
suitability  of  implementation  and  verification  conceptsy  a  part 
of  which  has  been  Introduced  in  the  previous  chapters*  This  is 
the  main  chapter  of  the  thesisy  and  it  may  be  understood  as  a 
collection  of  (hopefully)  clarifyinK  comments  &  nd  new 
contributions  concerning  the  verification  of  concurrent 
a  Ifcor  1  thms  • 

The  selected  applications  are  popular  and  widely— ;ised  in 
concurrent  profframminsr*  If  they  appear  a  little  arbitraryy  keep 
in  mind  that  their  only  purpose  is  to  illustrate  verification 
concepts*  We  do  not  attempt  to  cover  the  most  important 
alajorlthms  for  concurrent  proflcrammi  ng;  • 


4*1  Ar gu i n g  Opt  L  rea 1  Scheduli ng  of  Proc esses 

Sync  hron I zed  by  Semaghores 

This  section  discusses  the  structure  of  arRuments  for 
efficient  schedulinR  in  a  parallel  programminR  environment*  As 
example  serves  the  proof  of  the  property  of  a  semaphore 
a  dmin  ister  ins  a  section  of  critical  code  y  to  Rrant  entry 
whenever  the  critical  section  is  executed  by  less  than  a 
constant  numbery  my  of  processes*  Whereas  the  former  part  of 
the  requirement  (to  Rrant  entry)  characterizes  the  semaphore's 
schedulinR  tasky  the  latter  ("whenever***”)  is  an  efficiency 
c  ons t  ra  i  n  t  • 

We  shall  study  several  semaphore  implementations  that  have 
been  publlshedy  and  investieate  the  requirements  that  are 
necessary  for  the  verification  of  the  above  schedulinR  property* 

The  first  implementation  and  its  proof  is  taken  from 
[OwGr76a]*  It  uses  the  Reneral  concurrenf  statement* 
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a  :  =  m  ; 

cobggl_n  Si //S2//«  •  .//Sn  co«nd; 
where  each  Si  has  the  rform 
Etlii®  true  do 

h^eLn 

n on—c rl t I ca 1  section? 
p(«) ; 

critical  section? 

V  (a)  ? 

non-critical  section? 
end  ? 

MoreoveCf  the  Si  handle  s  like  a  semaphoref  1 ve* f  do  not  access 
s  except  in  calls  to  P  and  V  where 


P(  s )  5  SLHiil  a>0  [a  s— I  ] 

V(s)  =  [a  :=  S4-1] 


Here*  —  means  that  the  left  operand  is  a  substitution  for  the 
ri!{ht  operand*  (Rememberf  the  language  does  not  contain 
procedures • ) 

To  prove  the  scheduling  property*  we  relate  the  execution 
of  the  different  processes  to  each  other  by  auxiliary  variables* 
For  every  process  Si*  the  binary  auxiliary  variable  INC(i] 
indicates  whether  SI  is  currently  executing  the  critical  section 
protected  by  the  semaphore  (INC(1]=1)  or  not  ( INC[  i  ]  =  3 ) *  The 
scheduling  property  of  the  semaphore  is  then  expressed  by  the 
i nva riant 

n  n 

I  ~  (0<s=ni-  5  INClij  A  A  INCC  i  ]c  (0*  1)  ) 

1=1  i=l 

That  is*  the  semaphore  value  must  represent  exactly  the  number 
of  processes  that  may  still  enter  the  critical  section* 

Presuming  that  the  semaphore  and  the  auxiliary  variables 
are  only  referred  to  in  places  explicitly  shown*  the  proof 
o  ut 1 i ne  is! 
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a  ;=  m; 

IHC[  I  J  ,  INC[21  INC[  n]  :=  0«0y««0; 

”I  A  A  INC[l]=0»» 

1  =  1 

cobegin  S1//S2// • • • //Sn  coend; 
a Ise” 

•There  for  every  SI 

”I  A  INCtil=0” 
whlJLe  true  do 
begin 

•*T  A  INC[1)  =  0»* 

non— critical  section; 

" I  A  INC[  1 1  =  0  " 

await  a>n  [s  :=  s-1;  iNC[i]  :=  11; 

»•  r  A  iNc[  1  ]  =  i " 
critical  section; 

"T  A  INC[il=l« 

[a  ;=  34^1 ;  iNCC  1  ]  :  =  0] ; 

»»T  A  INC[i]=0” 

non— critical  section; 

"  I  A  INC[  1 1=0  »» 
end  ; 

”  f  a  Ise** 

The  postcondition  is  false  to  indicate  that  the  process  does  not 
terminate  execution* 

in  the  proof  of  Sif  every  assertion  is  i nt erf e renc e- free * 
since  all  processes  keep  I  invariant  throughout  their  executiony 
andy  of  the  auxiliary  variabiesy  Si  changes  only  IMC[il  which  is 
not  changed  by  any  other  process* 

The  invariant  also  yields  the  efficiency  constraint  on  the 
semaphore:  The  short  argument  that  requests  are  granted  as  soon 

as  less  than  ■  processes  execute  the  critical  section  is  given 
in  COwGr76al  (more  exactlyy  a  blocked  process  implies  that  m 
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processes  are  execu'ting  the  critical  section)* 

For  the  multiple  assleament  statesent  to  the  aaxiliarjr 
varlablesy  ve  use  the  simple  axiom 

Xl  y  •  •  •  y  Xn 

"P  **  xty***9xn  clf***fCn  ••p** 

C  t  y  •  •  •  y  Cn 

where  the  cly«««ycn  are  constants*  For  a  more  detailed 
discussion  of  multiple  assignment  axioms  see  (3rl78]* 

Let  us  briefly  review  the  strategy  of  the  outlined  proof; 
The  desired  property  follows  from  a  lemma  baaed  on  a  cleverly 
chosen  invariant.  The  Invariant  comprises  the  behaviour  of  all 
processes  that  access  the  semaphorey  by  means  of  auxiliary 
variables  that  each  describe  the  history  of  one  process.  (Some 
people  call  them  history  variables  [Bri73y  How76al.  )  Each 
auxiliary  variable  could  have  been  defined  locally  to  Its 
processy  rather  than  Joining  them  all  in  a  global  array.  Then 
the  precondition  for  each  process  SI  would  be  ly  and  IMCi=Oy 
where  TNCl  is  the  auxiliary  variable  of  Sly  would  he  established 
before  the  wh  1  le  loop.  The  present  version  has  been  chosen  for 
the  sake  of  analogy  with  the  following  example. 

The  structure  of  the  Invariant  depends  on  the  scheduling 
property  to  be  proven y  and  finding  it  may  require  a  good  deal  of 
intuition.  Owickl  makes  the  point  that  more  sophisticated  tools 
are  required  to  verify  optimal  scheduling  In  a  uniform  wayy  as 
opposed  to  termination  or  the  absence  of  deadlock* 

It  is  important  to  note  that  the  optimal  scheduling 
argument  is  based  on  the  assumption  that  Dwlckl's 

synchronization  schemey  the  i^slt  stateraenty  performs  optiaial 
schedullngy  i*e*y  delays  the  executing  process  only  until  Its 
resumption  condition  is  satisfied.  This  presumption  Is  a  hidden 
requirement  that  is  not  reflected  in  the  proof  rule  for  await. 
The  await  statement  Isa  very  high-level  synchronization  scheme* 
In  the  following  implementations  we  will  use  a  lower-level 
scheme  that  can  sufficiently  be  described  by  axiomatic  pre—  and 


pos tcondi t ions  * 
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Rather  than  detinin^  the  aeaaphore  as  a  global  irariabla  and 
giving  senantic  restrictions  for  Its  use t  one  should  incorporate 
it  as  an  abstract  data  tjrpey  as  nonitort  for  instance* 
Different  loonitor  i  spleme  nta  tions  of  the  aeaaphore  appear  in  the 
literature  (for  example  [ Hoa74f  Hov76a])*  He  define: 

t^Qe  semaphore  =  aoni tor ( a I  integer); 

^«l£! 

var  s:  integer; 

q:  condition; 

proc  P ; 
beg  i  n 

i  f  s=0  the  n  q*vait; 
s  :=  s-l ; 
end  P ; 

proc,  V ; 
begin 

s  :=  s+i ; 
q  vsi gnal ; 
end  V ; 

s  :=  m  end; 
end  semaphore; 

shared  sem:  semaphore  cobegin  Sl//*«*//Sn  cpend; 

where  the  Si  have  the  form 

wh lie  true  do 
begin 

non— critical  section; 
sem • P  ; 

critical  section; 
s  em • V ; 

non— critical  section; 
end  ; 


i 
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Having;  in  mind  to  carry  through  oxactly  tho  aaae  proof  aa 
in  the  previoua  prograflif  let  ua  apecify  the  propertl ea  of  the 
semaphore  monitor*  Following  the  proof  rule  for  the  concurrent 
statement  with  monitors  (chapter  3*2)#  we  wantJ 

n 

aema phore • I nl t  =>  ( B=m  a  a  IMC[il=0) 

i  =  l 

n  n 

semaphore*  I  <=>  (OiSs=a—  5  INC(i]  a  a  INC[i]e(Ofi)  ) 

i=l  i=l 

The  P  operation  wlil  define  the  entryt  the  V  operation  the  exit 
of  the  critical  section*  Thus  the  specifications  are! 


semaphore  Z 


integer  s 


Peqt 


In  it  : 

I  : 


Op er at  1  ons  Z 


m>0 


n 

s=m  A  A  TNC[1 ]=0 
i=l 

n  n 

0<s=m-  5  INCCi  1  A  A  TNCCi]e(0,l} 
1=1  1=1 

P 

pret  INC( ca 11 er ]= 0 
post:  INC[  call  er  ]=  1 


V 

prel  INC[ ca 11 er ]= 1 
post:  INC[ call er 1=0 


Because  the  auxiliary  variables  have  to  be  referenced  by  the 
semaphore  operationsf  they  must  be  part  of  the  monitor*  A 
definition  local  to  the  processes  is  not  possible  anymore* 
Here,  a  concept  arises  that  is  important  for  the  verification  of 
concurrent  programs  with  shared  abstract  data  types:  The  use  of 
♦♦private”  auxiliary  variables  In  the  shared  data  type 
(recognized  in  (Owl77al)*  All  accessors  of  the  data  object  need 
exactly  the  same  type  of  auxiliary  variable.  In  order  to  keep 
track  of  their  history  concerning  the  access  of  that  data  object 
that  will  be  recorded  inside  the  data  type  operations*  Hence, 
only  one  auxiliary  variable  la  declared,  but  the  t^pe  prefix 
p  r i va  te  indicates  that  each  accessor  has  Its  own  Incarnation* 


To 


distinguish  different  incarnations,  a  caller-id  is  implicit 
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paraneter  of  every  data  type  operatlonf  and  a  reference  to  the 
auxiliary  variable  x  in  soee  operation  actually  accesses  the 
private  auxiliary  variable  xl  caller  ]  of  the  caller* 

We  shall  see  later  that  the  concept  of  private  variables 
also  has  its  significance  for  the  1  apleaentation  of  abstract 
data  types*  Here  it  affects  only  the  proof*  since  we  only 
declare  auxiliary  variables  to  be  private*  The  proof  outline* 
usini^  the  rules  described  in  chapter  2*1  and  3*2*  is: 

type  seaaphore  =  a  on  1  to  r  (  a  :  in  teller); 
begin 

var  a:  integer; 

TNC:  auxi 1 i ary  pri ya te  of  0**1; 

<i:  condition; 


gro^  p ; 

beg  i  n 

"I  A  IHClcaller]=0»* 

if  s=0  then  "I  A  INClcaller  1  =  0  a  3=0” 

CT*  wa  it; 

"I  A  INCf  cal  ler]=0  a  s>0»» 
s  : =  s— I ; 

•«INC[  cal  ler  ]=0  a  s>0" 

INC  :=  i; 

"I  A  INCtcal  ler]  =  l»» 
end  P » 

pr oc  V ; 
begin 

•*I  A  INCC  cal  ler  1  =  1" 
s  ;  =  s-t  1 ; 

”INC[  caller]  =  l  a  s>0** 

TNC  :=  o; 

«I  A  TNCt  cal  ler  3=0  a  s  >0  ” 
cr  .signal ; 

••  I  A  INCr  cal  ler3=0" 
end  V  ; 
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beg  i  n 

8  :=  m;  INC  :=  o; 


”  I  A 
end ; 


n 

8=m  A  A  INC(il=0" 
1  =  1 


end  semtphore; 


n 

•M8=ni  A  A  INCti]  =  0)  =>  true** 

1  =  1 

**  t  rue” 

shared  sent  I  semaphore  cobe^ln  Sl//«»#//Sn  coend! 
”  false” 


where  for  each  SI 


”1  A  INC[1]=0” 
do 

begin 

”I  A  INC[1]  =  0" 
non— critical  section! 
”  I  A  INC[  1  ]  =  0  ” 
s  em • P  ; 

”  T  A  INC[  1  ]  =  l  ” 
critical  section! 

”T  A  INC[1]=1” 
s  em • V  ! 

”I  A  INCtl]  =  0” 
non— critical  section! 
” T  A  INC[  1 ]=0  ” 
end ! 

” f a Ise” 


Note  that,  by  using  a  lower-level  synchronization  scheme,  no 
scheduling  axiom  need  be  presumed*  The  fact  that  the  processes 
are  delayed  only  If  m  other  processes  are  executing  the  critical 
section  can  directly  be  drawn  from 


pre(q«wait)  =>  (cond) 
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That  processes  are  resunedt  inaediat e ly  vhen  soae  leave  the 
critical  section  is  derived  troa  the  Invariant* 


It  would  be  preferable  and  helpful  In  the  search  for  a 
suitable  invariant  to  enforce  optiiaal  scheduling  of  an  abstract 
data  type's  synchronization  schene  by  its  proof  rules*  [  How7 6a ) 
proposes  proof  rules  for  wait  and  sisnal  that  laply  optimal 
scheduling*  As  a  con  sequence t  the  callers  scheduled  by  the 
monitor  need  not  anymore  be  considered  in  the  proof  of  that 
property*  The  Idea  is  to  postulate  in  the  precondition  of 
cond.walt  and  in  the  postcondition  of  cond*signal  that  the 
resumption  condition  for  processes  waiting  in  c ond  is  false* 
The  exact  proof  rules  areJ 

"PaJaE”  cond*wait  ”  Pa  Ja  B(  co  nd )  ** 

”PaJaB(  cond  )  A-icond*  empty”  c  ond*  signal  ”PaJaF,” 

JaE  form  the  monitor  invariant  I*  where  E  is  a  terra  that  extends 
J  to  JaF  =>  -»R(cond)f  for  all  condition  queues  cond  in  the 
monltorf  and  P  is  as  before* 

This  more  explicit  structure  of  the  Invariant  forces  the 
verifier  to  produce  assertions  that  imply  optiraal  scheduling* 
The  inclusion  of  -•cond*  empty  in  the  precondition  of  cond*signal 
prevents  a  second  axiom  tor  execution  on  an  empty  queuey  where 
signal  acts  like  the  empty  stateaentf  sk^p* 

The  semaphore  implementation  is  very  similar  to  the 
previous  one! 

IXfi®  semaphore  =  *onltor{mt  integer); 
begin 

var  s:  integer; 


q:  condition; 
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Bri2.£. 

Hegin 

l_f  8=0  then  cr*wait; 

8  :=  s-1 ; 

end  P ; 

EI!oc  V ; 

beg  1  n 

8  :=  s-»-l ; 

i f  q«e*pty  then  q«slgnai; 

v; 

*i®S.jLD  ^  •“  **' 
end  setnaphot^e; 

The  only  difference  is  that  q«8ignal  is  prefixed  by  an  ^f  to 
ensure  its  precondition* 

For  the  prooff  ire  need  an  auxiliary  variable  tha  f  plays  the 
role  of  INC  In  the  previous  case*  Private  variables  are  of  no 
use,  since  ve  do  not  want  to  consider  the  callers  of  the  monitor 
i  ndi  V  i  dua  1  I  y  y  as  ve  did  before*  The  solution  is  to  keep  track 
of  the  queue  lengths  for  condition  queues  in  the  monitor*  They 
are  the  only  11  nk  to  the  processes  if  one  only  wants  to  regard 
the  monitor  in  the  verification*  For  each  condition  cond  in  the 
monitor*  we  introduce  an  auxiliary  variable  condlen*  the  queue 
length  of  cond* 

In  the  special  case  of  the  semaphore*  the  length  of  q* 
qlen*  dually  extends  s*  The  expression 

S  —  8— qlen 

could  be  interpreted  as  a  ”hyper'*-semaphore  with  extended  range 
in  the  negative  Integers*  is  the  logical  condition  for 

synchronisation  to  take  place*  If  5  decreases  to  5<0  *  a  delay 
is  necessary;  if  5  increases  to  5  =  0*  a  resumption  must  be 
performed*  A  valid  invariant  Is 

J  5  ( min( s* qlen) ^0) 
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Rut  it  floes  not  yield  optimal  scheduling*  We  vish  a  vaiting 
process  to  be  resumed  as  soon  as  the  semaphore  value  becomes 
creator  than  zero «  l«e««  the  eapliclt  resumption  condition  Is 

B(q)  5  <8=1  ^  qlen>0) 

but,  unfortunately 


J  *>  -.B(q) 


The  additional  requirement 


F  5  (  mi  n(  8,  qlen  )  !S0) 

extends  J  appropriately,  such  that  the  desired  invariant  is 

JaE  =  I  5  ( min ( 3 , qle n) =0 ) 

With  this  invariant, 

B(q)  =>  S<0 

i«e*,  resumption  only  takes  place  when  S<0  and,  moreover,  the 
code  of  P  shows  that  a  delay  occurs  only  if  S<0«  Hence, 
synchronization  is  performed  only  when  it  is  logically 
n  ecessa  ry • 

The  specifications  of  this  semaphore  are  simple: 


se  ma  ph  ore : 


integer  s 


Req: 
Tn  i  t : 
I : 


ni>0 

s=m  A  ql  en  =  0 
ml  n ( s, ql en ) =0 


Op er at i ons  t 


P 

pre:  true 

post  I  false 


V 

pre!  true 
post  :  false 


The  trivial  rules  for  the  se 


phore  operations  (any  assertion 
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may  serve  as  pre-  or  postcondition) $  as  opposed  to  bcforet 
illustrate  that  indeed  no  callers  are  involved  in  the  proof* 

Let  us  first  ^ive  the  proof  outline  and  then  discuss  its 
p  robi ems  Z 

type  semaphore  =  moni t or ( ■ ? integer ) ? 
heg^n 

XiL  si:  integer; 

Qlen!  SJi5l.li.arj  integer; 
q  :  c  ond  1  t  i  o  n; 


gr oc  P ; 
beg^n 

ti  { II 

qlen  Z=  qlen+l; 

”mi  n(  Sfqlen— 1)  =  0** 

i_f  3=0  then  **s=0  a  qlen^l'* 

q*  wait; 

”s=t  A  qlenil” 

'*min(  s,qlen)  — 1=0” 

s  ; =  s-l  ; 

qlen  :=  qlen—1; 

II  j  II 

end  P ; 

y 

g r oc  V  ; 

begin 

M  jn 

s  : =  s+ 1 ; 

”  mi  n{s— 1  ♦qlen)=0” 

i_f  -•q.empty  then  "s=  1  a  qlen>0  a  -*q«  empty” 

q*  signa i; 

II  j  11 


end  V ; 
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hegl  n 

s  :=  a;  crien  0; 

"I  A  8=a  A  qlen=0** 
end  ; 

end  seaaphoee; 

The  prooT  is  acceptable  as  long  as  one  preauaes  that 

-«q«eapty  <=  >  qlen>0 

at  least  In  the  precondition  of  q*signal«  i«e«t  that  qlen  really 
counts  the  waiting  processes  properly*  It  would  be  best  to  make 
this  assertion  part  of  the  invarianty  but  unfortunately  it  is 
not  invariantly  true* 

tHow76a]  performs  a  similar  proof  on  the  basis  of 
Habermann's  semaphore  specifications  [Hab72  ]*  Substitute 

s  =  nr-np 

I 

qlen  =  na— np 

Howevery  then  V  contains  a  test  on  qlen>0  rather  than  on 
-«q  .empty  whichy  according  to  Howardy  implies  a  non-empty 
condition  q*  This  results  in  a  change  of  the  auxiliary  variable 

qlen  to  a  program  variable  and  makes  the  semaphore 

i mol emen t at i on  entirely  artificial* 

For  the  proposed  proof  rxilesy  the  use  of  auxiliary 

variables  is  essential*  Without  them y  the  frequent  case  of 
synchronized  calls  to  monitor  operations  (in  which  wait  and 
signal  frame  the  procedure  body)  is  not  verifiable*  The 
meaningful  use  of  wait  requires  at  least  one  assignment  before 
its  call  in  the  monitor  operation* 

The  cause  of  all  the  troubles  is  that  the  proper  updating 
of  qlen  is  the  responsibility  of  the  verifier  (or  even 

programmer)  and  has  to  be  ensured  by  the  intermediate  assertions 
in  the  monitor  operations*  qlen  should  instead  be  an  auxiliary 
variable  manipulated  only  inside  wait  and  signaly  and  not  burden 
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the  alfzorithtas  defining  the  monitor  procedures* 


This  motivates  a  nev  concepty  the  concept  of  a 
variable  which  only  appears  in  assertions  and 
algorithm*  Proof  rules  in  this  spirit  are  defined 
The  hidden  variable  cond* len  plays  the  role  for 
auxiliary  variable  condlen* 


hidden  proof 
not  In  the 
in  [ H  ow76b ] * 
the  former 


♦  ♦ 

"PaJ  aF  ”  cond*wait 

”  Pa  J  A  B(  cond  )  **  cond*8ignal 
’'cond*len>0”  b  1=  cond*  empty 


*  * 

wpAj  aB  (cond)” 
"Pa  JaE” 

"b*  =( cond*] en=0  )  " 


where  for  every  condition  cond  in  the  monitor 

B(cond)  =>  cond*len>0 

♦ 

The  superscript  indicates  the  substitution  of  cond*len+l  for 

cond*len*  The  internal  axiomatic  requirements  on  cond*len  are 

initially;  *  cond*len=0 

invariantly;  cond*len^O  a  (cond*len>0  <=  >  -»c  ond*  emp  t  y ) 

These  proof  rules  reflect  that  cond*len  Is  incremented  at  the 
start  and  decremented  at  the  end  of  each  waiting  period* 

With  unaltered  sp eci f Icat Ions y  the  proof  outline  is; 

t^pe  semaphore  =  raonJLt  ®£!  (  ■•  *  Integer); 
besJ.n  ^ 

var  s;  integer; 

cr ;  c  ond  1  tl  on; 

proc  P ; 
begXH 

" I  A  I en>0  " 

^f  s=0  then  "s=0  a  q*lentl>0" 

q*  wa  i  t  ; 


”s  =  l  A  q*len  +  l>0" 
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**0<ini n{  s  y  q«  I  en  )  <  1  a  8=1" 
s  ;=  s-1 ; 

**  I  A  1  en  >0  *• 
end  P; 

£roc  V; 
beg_i  n 

"  I  A  Q.  len>0" 

8  : =  8+1 ; 

"mln(8-l  »q»len)  =  0” 

1  f  -'q.empty  then  "s=l  a  q«  len>0" 

q«  s ig na 1 ; 

"1  A  q • 1 en>0 ” 
end  V; 


beg i  n 

"in>0" 
s  :  =  m ; 

"T  A  8=ni  A  q*len  =  0" 
end  I 

end  senaphoret 

This  proof  ends  the  investigation  of  the  verification  of 
optimal  scheduling  by  semaphores* 


We  started  with  an  i  aplement  at  ion  by  the  general  concurrent 


statement  that  does  not  isolate 
concurrent  environment*  The 
variables  provided  us  with  an 
dynamic  behaviour  of  the  system 


the  semaphore  structure  from  its 
popular  concept  of  auxiliary 
invariant  from  which  the  desired 
could  be  cone luded* 


Defining  the  semaphore  as  a  monitor  enabled  a  proper 
specification  of  its  characteristics*  k  second  concepty  the 
private  varlabley  interrelated  the  abstract  data  type  and  Its 
accessorsy  yielding  the  same  invariant  as  in  the  first  case* 

Particularly  restrictive  monitor  proof  rules  and  a  new 
representation  of  its  accessors  in  the  proof  by  means  of  a  third 
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concept,  the  hidden  variable,  guides  the  verifier  in  the 
development  of  assertions  that  imply  optimal  scheduling* 

We  do  not  intend  to  rate  any  of  these  techniqr'*®s  over  the 

others*  The  general  concurrent  statement  is  useful  for  the 

hand] ing  of  dynamically  changing  shared  data  sets,  as  in 
[Gri77]*  The  verification  of  monitors  with  private  variables  is 
suitable  for  static  shared  data  specifications  with  external 
properties  (i*e*,  non— trivial  proof  rules  for  the  operations  on 
them)*  In  the  case  of  the  semaphore  which  only  bears  a  purely 

internal  synchronization  property,  the  restrictive  monitor  proof 

rules  seem  most  suitable* 


4*7  S  i  mpl  i  f  y  i  ng  jthe  Reso  ur  c  e  Poo^  I  mpl  emen  ta  ti  on 

The  purpose  of  this  section  is  to  Investigate  the 
suitablillty  of  several  langmge  constructs  and  their  proof 
rules  for  the '  imp  lementat  ion  and  verification  of  an  abstract 
data  type  that  allocates  resources  from  a  pool  for  private 
access*  We  shall  start  with  a  very  general  approach  and 
discover  the  trade-offs  in  security  and  ease  of  verification  by 
restrictions  that  are  appropriate  for  this  specific  problem* 
Since  resource  allocation  is  an  important  operating  systems 
concept,  restrictions  for  its  easy  use  seem  worthy  of 
influencing  the  design  of  a  systems  language* 


We  shall  start 
private  pool  object 
related  to  these 
that  interprets  the 
ob Jec  t  R : 


with  specifications  that  define  the  abstract 
R*  The  subsequent  implementations  will  be 
specifications  by  the  abstraction  function  F 
concrete  implementation  C  as  the  abstract 


R  =  F(C) 


(For  more  details  see  the  introduction  to  chapter  2*) 


c  • 
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The  private  pool  vill  adainiater  a  aet  R  of  shared 

resources  r  whlsh  are  either  in  private  use  or  free: 

1 

(r)-R  UR 

ir unit  id  i  in use  free 

denotes  the  distinct  union*)  Each  of  the  resources  in  use 
will  beloni^  to  one  and  onljr  one  process! 

R  E  U  R  (caller) 

inuse  ca i 1 er e p roce ss i d  inuse 

These  are  the  properties  that  characterize  the  abstract  object 
and  that  have  to  be  preserved  by  the  operations*  Fnitiaiiyt  all 
resources  will  be  available! 


R  =  C)  A 

1  n  use 

The  specifications  of  the 
operations  follow* 


R 


u  (r  } 

ieunltld  1 


f  r  ee 

pre—  and  postconditions 


for  the 


With  some  resemblance  to  [FlHa76]f  the  abstract  private 
resource  pool  may  be  summarized  to! 


prlvatepool!  R  - 


U  (r  ) 

ieunltld  i 


Req  : 
Ini  t  : 


T : 


true 

R  =  (  )  A  R  =  U  (r  ) 

inuse  free  ieunltld  i 

A  A  r  Inltiall ze  d 
reH 

R  =  R  UR  A 

inuse  free 

R  =  U  R  ( cal ler ) 

inuse  c a I  1 e re proc essi d  inuse 


Ope ra  1 1 ons 


ee  t  (  r ) 
pre!  true 

post  !R»  =P  “(rjA 

free  free 

R*  (cailcr)=R  (caller)U(r) 

inuse  inuse 
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put( r) 


pre!  re R 

(cal  le 

inuse 

post  I  R •  =R 

U  [r 

free  free 


R*  (caller) 

1  nuse 


opi  (  r  f  *  •  *  ) 

pre  Z  re  R 

(calle 

1  nuse 

post:  reR 

(c  al  le 

1  nuse 

op  2 (  r y  * • *  ) 

r ) 

)  A 

=R  {caller)-(r} 

inuse 

r )  A  •  •  • 
r )  A  •  •  • 


Note  that  the  pool  contains  the  administrative  as  well  as  the 
resource  driving  operations* 


We  shall 
prootSf  given  in 
first  present 
and  then  give 
operations  get 
trivial  and  left 
non— 1 nter  fere  nee 


nov  proceed  with  the  1  mplemen  ta  ti  on  s  and  their 
a  somewhat  abridged  fora*  In  every  case^  we 
the  proiEram  text  Including  auxiliary  variablest 
a  proof  outline  for  the  two  administrative 
and  put*  The  proof  of  the  initial  statement  is 
out*  After  that  follows  an  argument  about 


The  first  1 mpl emen ta 1 1  on «  taken  from  (0wi77b]f  uses  a 
general  shared  class*  It  permits  complete  control  orer  the 
exclusion  mode  between  any  two  statements  within  the  class 
operations*  The  synchronization  tool  is  the  semaphore*  Our 
intention  is*  of  courset  to  provide  mutual  exclusion  of  get  and 
put,  and  to  allow  any  statements  of  driving  routines  to  execute 
c  oncurrent  ly* 
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t  ype  unltld  =  1 • • u ni tc oun t ; 

type  privatepool  =  sh  a  re  d  c  1  as  a; 
begi  n 

va  r  poo  It  unltid  of  resource! 

free:  Eowerset  of  unltld! 
freecounty  mutex!  semaphore! 
owner;  unltld  of  processld! 

m:  auxl  11  ary  arraj^  processld  o^  0*«l! 
ay  b:  ai.uxi.lXa  r£^  Integer! 

proc  ge t ( va r  unit:  unltld)! 

*>egln 

[  f  reec  ount  •  P  !  a  !=  a+1]! 

[mutex.P!  mtcaller)  :=  Ij! 
unit  :=  oneof(free)! 
owner[unlt]  !=  caller! 

[free  :=  free- (unit) !  a  !=  a-1 ] 
[fflutexvV!  m[  caller]  !=  0]! 
end  ge  t ! 

proc  put (unit:  unltld)! 
begl  n 

1  f  owne  r (  uni  t  )  al  1  e  r  the^  return  ! 

[  mutex#  P!  ra(  caller]  :=  1]! 

[free  :=  freeU[unit)!  b  Z=  b  — 1]! 
owncr(unit]  I-  nXlI 
[rautexaV!  m(caller]  :=  0]! 

[  fr  recount  •VI  b  !=  b+l)! 
end  put  I 

proc  o  p  t ( un it!  un itld!»««  )! 
begi  n  operate  on  pool  [unit]  end! 

proc  op2(unlt:  unltld!***  )! 


•  •  • 
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beg  i  n 

free  :=  allunite; 

freecount  :=  unltcount;  mutex  Z=  15 
owne  r  : =  nil; 
a  :=  b  ;=  m  :=  0; 

for  i;  =  l  unltcount  ^  ifiii  pool  Cl]; 

enrt ; 

end  private pool; 

allunits  is  the  set  constant  of  all  one— element  sets  In  the 
powerset  of  unltid*  The  odd  J^f  statement  in  put  (rather  than 
defining  the  entire  procedure  as  1  f  with  the  complementary 
condition  and  saving  the  return)  Is  due  to  the  required  enter; 
operate;  exit  format  of  class  operations  (see  section  2*4  )• 


Owlcki  gives  very 
for  the  private  poolf 
abstraction  function  (we 
In  the  last  section)* 
define  the  mapping 


impl  emen  ta  1 1  on— or  i  en  ted  sped  fl  cations 
which  saves  her  from  considering  an 
did  the  same  for  the  semaphore  monitor 
This  function  is  our  next  concern*  We 


R  =  F ( free » owner ) 


where 


R  -  Cijiefree  a  owner  I  1  ]=  nl  1) 

f  ree 

/ 

R  -  (l|l/free  a  owner  [  1  nl  1) 

1  nuse 

R  (caller)  -  (l)l/free  a  owner  ( 1  ]  =  call  er) 

i  nuse 

The  assertion 


A  (icfree  <= >  owne r[ 1 ]=nl 1 )  a 

1 eunl t 1 d 

Implies  the  abstract  invariant  I(R)f  but 
class  invariant^  because  unfortunately 
violated*  The  reason  is  that  get  and 


OS  J  free | <uni  tcount 

does  not  suf f ice 
Its  invariance  may 
put  do  not  prope 


a  s 
be 
r  ly 


exclude  each  other* 
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The  shared 
I  n  our  case « 
synchronirati on 
freecount •  The 


class  uses  setRai^ores  as  a  synchronization  tool* 
the  size  of  the  free  set  determines  the 
and  h& 8  to  be  expressed  by  a  seeaphoref 
desired  relation  is 


freecount  =  | f ree i 

Rut  this  cannot  be  Invariantly  maintained*  The  synchronization 
on  freecount  has  to  be  performed  outside  the  critical  section  of 
the  mutual  exclusive  rest  of  the  operations^  in  order  to  avoid 
deadlock*  Hencef  the  proper  maintenance  of  the  equality  may  be 
Interrupted,  and  callers  may  find  freecount  decreased  without 
accordinR  reduction  of  free  (by  get),  or  the  free  set  extended 
without  proper  update  of  freecount  (by  put)*  Two  auxiliary 
variables,  a  and  b,  keep  track  of  these  cases*  The  invariant 
equal i ty  Is 

freecount  =  |free|+b— a 

The  sequencing  of  the  auxiliary  variable  updates  (differing  from 
rOwl77b])  ensures  that  always  a>0,  b<0,  and  thus 


freecount  <  Ifree) 


This  indicates  that  the  semaphore  synchronization  may  not  be 
optimal,  because  not  all  freed  resource  objects  may  immediately 
be  counted*  It  turns  out  that  semaphores  are  a  synchronization 
concept  that  is  sometimes  too  constrained  and  not 
problem-oriented*  Here,  it  leads  to  an  unnecessarily  weak 
invariant*  (In  this  particular  case,  the  wi t h- when  statement 
resolves  nil  problems*) 


The  auxiliary  array  m  yields  the 
invariant,  quite  similarly  to  the  private 
semaphore  monitor  in  the  previous  section* 


mutual  exclusion 
variable  INC  for  the 
The  entire  class 


I  n var i an t  is 
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I  3  ^  (lefree  <=>  owne  r(  1  ]=nil ) 

ieunl tid 

A  freecoun^  -  lfreej-*-b— a 

A  0^:fr  eecoun't^uni'tc  oun  t  a  0<autex<l 

A  mutex  =1—  5  ■[ caller] 

call er eprocesa id 

Let  u«  proceed  with  the  proof  outline  for  the  private  pool 
operations.  We  will  use  the  followlnt{  axioms  that  are  not 
stated  in  the  references: 


a)  Let  Xf  ^  he  set  variables 

*'s^  C)  ••  X 

In  the  private 
causes  no  harm 
only  contains 

h) 

c  ) 


The  n 

oneof(s)  ”xes" 

variable  of  type  unitid*  That 
representation  of  Sf  freet 
unitid  with  cardinality  !• 


pool f  x  1 s  a 
f  because  the 
subsets  from 

”sein>0”  seni.P  "  sem*  =nia x  ( 0  f  setn— 1 ) '* 

'*sem>0”  sem.V  ”  sera*  =8eBi+ 1  *• 


The  outline  for  the  two  procedures  get  and  put  is: 
getfvar  unit;  unitid); 

begin 

fi  I'll 

[  f r cecount  •  P ;  a  Z—  a-*- 1  ]  ; 

"I”  (i) 

[mutex.P;  mtcaller]  :=  1]; 

II  I II 

unit  :=  oneof(free) ; 
ownertunit]  :=  caller; 

'*unitefree  a  owner[  uni  t  ]=  ca  Her  ** 

[free  :=  free-Cunit];  a  :=  a- 1  )  ; 

A  ow  nerf  un  i  t  )  =  cal  1  er  *' 

[mutex.V;  mtcaller]  :=  0]; 

”I  A  ownerC  uni  t  ]  =  caller»»  (Implies  get.post) 

en  d  get ; 


proc  put  (unit:  unltld); 


(follovs  trom  put«pre) 


”I  A  owne rC  uni  t  ]  =  ca  1 1 er” 

If  owne r[ uni t ] ^call er  then  return; 

”I  A  owne  r(  uni  t  ]  =  ca  Her  ” 

[mutex.P;  mCcaller]  :=  1]; 

”r  A  ownert  unit  ]  =  caller” 

[free  I-  freeU(unit};  b  :=  b-1]; 

”unitefree  a  owner(  un i  t  ]  =  ca  Her” 
ownerlunit]  :=  ni 1 ; 

”I  A  unite  free” 

[mutex.V;  mtcaller]  :=  0]; 

”T  A  owner[  un  it]  #ca  Her”  (ii) 

r f r eec oun t • V ;  b  I—  b+ 1 ] ; 

”T  A  ownerE un i t  ]*ca 11 er ”  (Implies  part  of  pat*post) 

end  put ; 


To  show  non-interference  is  always  a  very  tiresove  task* 
It  will  not  be  argued  here*  £Owi77b]  states  the  general 
technlrfue  and  gives  some  examples*  Several  remarks  are  due^ 
t  hough • 


The  non-interference  of  get  and  put  is  not  as  trivial  as 
[Owi77b]  says*  If  the  operations  were  each  one  entire  critical 
section*  nothing  were  to  be  proven*  But  in  the  present 
implementation  the  assertions  marked  (i)  and  (ii)  have  to  be 
checked*  First*  note  that  both  (i)  and  (ll)  imply  the  Invariant 
I*  a  necessary  requirement  for  non-interference  (see 
section  2*3)*  Since  (i)  is  only  the  invariant*  there  cannot  be 
interference*  But  (ii)*  in  fact*  has  to  be  relaxed  so  that  the 
p os tc ondl t ion  of  put  only  Implies  a  part  of  the  specification 
pu  t • pos  t : 


R  •  =  R  U  ( r) 

free  free 

i  s  not  guaranteed*  Another  process  may  have  interrupted  the 
execution  of  put  and  Just  taken  the  resource  r*  This  is  not 
harmful*  though.  What  we  really  want  the  private  pool  to  do  is 
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n  ot  t  o 

lose 

freed  resourcesy  and 

the  invariant 

toge  ther 

wi  th 

the 

verlf  iah  le 

pa  r  t 

of  put*  post  state 

thaty 

if  the 

resource 

r  is 

not 

f  ree  y 

it 

must 

be  in  use  by 

some 

other 

process* 

I  n 

the 

Bpeci  ficBL'tionSy 

put«posit:  R*  (caller)  =  R  (caller)  — (r) 

Inuse  louse 

really  would  have  aufflcedy  and  wo  revise  It  acc  ordl  ngly  f  now« 
Althoui^h  we  do  not  have  to  test  the  pre—  and  postconditions  of 
the  operations  for  non-interference  in  the  proof  of  the  abstract 
data  type»  In  the  verification  of  the  callers  a  too  strong 
specification  may  cause  problems*  We  started  with  the  usual 
private  pool  specifications  (as  In  (FlHa76»  Owl77bl)  to  become 
aware  of  the  problem  of  over spec  1 f Icat ion*  The  following 
discussion  builds  on  the  relaxed  pool  specifications  (even 
though  the  stron<3[  specifications  night  be  satisfied)* 

[Owi77bl  points  out  the  problem  of  overspeci f i ca t ion  In 
another  respect*  The  rules  for  P  and  V  aay  cause  interference 
if  too  strong*  In  factf  the  axioms  we  use  are  not 

1 n ter ference  — free  *  Therefore  we  Joined  the  call  to  the 
semaphore  operation  in  an  elementary  action  with  an  appropriate 
auxiliary  variable  assignment  that  relates  the  auxiliary 
variable  1 n te rf erenc e- f re e  to  the  semaphore  state*  We  then  only 
referred  to  this  i  nt  er  f  erenc  e— free  relation  rather  than  a 
specific  semaphore  state* 

The  enter;  operate;  exit  format  required  for  class 
procedures  is  in  this  easel 

[ f reecount * P;  a  :=  a+l ) 

skJLc 

skip 

[  f  reecount*  V  ;  b  ;=  bt-l] 

The  variables  mutex  and  a  are  not  control  variablesy  although 
they  are  really  synchronizing*  The  latter  isy  howevery 
reflected  by  the  fact  thaty  in  the  proof  outliney  they  only 


get  .enter 
ge  t • ex  i  t 

pu  t • en  te  r 
put*  exit 


-  B3  - 


appear  in  the  c la bs  invariant  (compare  section  2«4)* 
Identlfyint?  the  set  of  control  variables  with  that  of  the 
synchronizing  v^arlables  was  not  possible  because  of  the  danger 
of  deadlock  in  the  procedure  get*  Joining  mutex*  P  and 
freecount*P  in  one  elementary  action  would  have  violated  the 
enter;  operate;  exit  formatf  but«  It  seenSf  still  would  have 
lead  to  a  verifiable  class,  even  with  a  put  procedure  that 
satisfies  the  stronger  specifications  (for  the  sake  of  coarser 
concurrency)*  The  necessity  of  a  special  format  requirement  is 
at  least  not  immediately  obvious* 


The  occurrence  of  a  P  operation  Inside  an  elementary  action 
requires  a  little  explanation*  In  the  proof,  the  statement 

freec ount  *P; 


for  instance,  is  replaced  by 

[  free  count*  P;  a  a*-l); 

where  a  is  an  auxiliary  variable*  (Because  accesses  to 
auxiliary  variables  will  never  be  executed,  they  may  appear 
unrestrictedly  inside  elementary  actions*)  However,  this 

statement  is  as  little  an  elementary  action  as  the  P  operation 
itsel f*  For  P,  there  are  two  cases! 

a)  The  caller  is  not  delayed  in  P* 

Then  P  is  elementary,  and  so  are  statements  [S]  containing 
a  call  to  P* 


b)  The  caller  is  delayed  in  P* 

Then  there  are  two  elementary  actions! 
i )  the  delaying  of  the  caller,  and 

li)  its  resumption  and  the  update  of  the  semaphore* 


Nontheless,  generally  Pis  said  to  be  elementary,  and  the  delay 
action  is  interpreted  as  synchronizing  mechanism  for  the  call  to 
P  rather  than  as  part  of  P.  If  one  adopts  this  view  for 
elementary  actions  whose  first  statement  is  a  call  to  P, 
orocesses  will  possibly  be  delayed,  but  before  the  execution 


of 
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the  elementary  artlon*  The  semantics  are  the  same  as  for  the 
awal  t  synchronization  in  the  general  concurrent  statement* 

As  already  discussedf  the  difficulties  irlth  the  invariant 
can  be  overcome  by  a  higher- level  synchronization  scheme*  To 
equip  the  shared  class  with  Si statements  rather  than 
semaphores  might  be  too  restrictive  for  a  flexible 
spec! liability  of  the  concurrency  relations,  its  most  important 
property*  Our  application  does  not  need  a  very  fine  concurrency 
trraln,  and  we  may  use  a  more  structured  approach  to  the 
synchronization  in  shared  data  types,  the  path  expression*  In 
this  scheme,  the  operations  nay  be  defined  either  mutually 
exclusive  or  entirely  concurrent  to  each  other*  For  our 

p^irpose,  this  is  sufficient*  We  do  not  require  partial 
exclusion  of  ooeratlons*  Moreover,  if  the  calls  to  operations 
are  synchronized,  the  execution  of  mutually  exclusive  operations 
is  guaranteed  not  to  be  interrupted*  The  i np le me n ta t 1  on  i si 

type  private  pool  =  c  1  a  as  ; 
heg^n 

yar  pool:  yyray  uni  tl  d  of  resource; 
free:  i>ower  set  of  unitid; 
owner:  accay  unitid  of  process!  d; 
uni tcoun  t 

i2at_h  [(get-put)  ,  opt,  op2,***)  end; 

/ 

proc  get{yar  unit:  unitid); 
begin 

unit  :=  oneof(free); 
owner[unlt]  :=  caller; 
free  : = 
end  pe  t ; 


free—  Cun  1 1 }  ; 
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proc  put (unit:  unit id); 
hegi  n 

i  f  owner! uni  t]=caller  then 
begin 

free  :=  freeU  (uni  t)  ; 
ownerCunit]  :=  nLJl* 
end; 

end  put ; 

proc  opl(unit:  unltid;..,); 
begin  operate  on  pool  [unit]  end; 

nnee  op2(unit:  unitid;*..); 

•  •  • 

begin 

free  :=  aliunits; 
owner  :=  n i_l  ; 

for  i:  =  l  to  unit  count  inii  pool[i  ]; 

end ; 

end  privatepooi; 

The  abstraction  function 

R  —  F( free f owner ) 

stays  as  beforet  but  the  invariant  is  now  as  desired 

I  —  A  (lcfree<  =  >  owner  [  i]  =  nll)  a  0<lfree|  <unlt  count 

ieuni tld 

Additional  assertions  to  derive  proper  synchronization  are  not 
necessaryt  since  the  path  expression  defines  all  that.  (For  the 
expression  syntax  see  section  2«3*)  All  driving  operations  may 
execute  concurrently  to  each  other  and  get  and  put,  whereas  the 
two  latter  are  mutually  exclusive.  Moreover 

0  <  #( get ) -# ( put )  <  unltcount 

is  enforced  by  synchronizing  the  calls  to  get  and  put.  The 
proof  outline  is  now  easy: 
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ge  t  (  va  r  unit:  unltid); 

be^j^n 

II  j  II 

unit  ;=  oneot' I  f  ree  )  ; 

”un  i  f  ree'* 

owner[unit]  :=  caller? 

'♦unltefree  a  ow  ner(  uni  t  ]=  ca  1 1  er  ** 
free  r=  free-  (uni  t)  ? 

’*  I  A  owner(  un  i  t  ]  =  ca  1 1  er  ”  (implies  get.post) 

end  ge t  ; 

pr oc  put(unltl  uni  tid)  ? 
begin 

'*  T  A  owne  r[  uni  t  ]  =  c  a  1 1  e  r  ”  {follows  from  put.pre) 

l_f  owner  (  un  i  t  ]  =  ca  I  1  er  then 

h  e  fT  i  n 

"I  A  own e rl uni f ] =c a 1 1 e r" 
free  :=  freeU(unit}; 

”unitefree  a  owner [ uni t ]=cal ler” 
owner[unltl  !=  nj^J^J 
•*  I  A  unite  free** 
end  ; 

”T  A  owne  r  [  uni  t  ]  al  1  e  r**  (implies  put«post) 

end  put ; 

/ 

The  invariant  term 


0< I  free | <unitcount 

is  preserved  because 

|free|  =  u  ni  t  count— (  /^  (  go  t  )  —  #(  put  )  ) 

Non-interference  of  the  operations  is  proven  as  be  fore y  where 

the  mutual  exclusion  of  get  and  put  is  now  really  trivial* 

The  merits  of  the  path  expression  are  apparent;  All 
synchronizing  and  their  associated  auxiliary  variables  disappear 
from  the  proof*  The  path  expression  provides  the  control  part 
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of  the  cJ ass  Invariant*  (Note  that  the  procedures  are  bound  to 
bear  the  enter;  operate;  exit  fornuit*)  The  data  part  of  the 
invariant  has  to  be  derived  In  addition  from  the  semantics  of 
the  operations* 

How  serious  the  restrictions  in  synchronization  with  path 
exoresslons  are  is  debatable*  In  our  casef  they  are  only 
a  dvan  t  aaje  ous  * 


The  third  implementation  uses  the  recently  introduced 
manager  data  type  for  the  dynamic  allocation  of  resources*  Its 
purpose  is  to  administer  the  access  capabilities  (as  cal  led  in 
the  original  paper  CSKB77])  to  the  objects  in  the  resource  pool* 
The  granted  resourcOf  iarplemented  as  a  private  class  object,  is 
then  directly  accessible  by  the  owner  process*  The  advantage  is 
that  the  owner  process  implicitly  gets  access  to  the  actual 
resource  object  rather  than  an  identification  that  could  be 
misused  or  get  lost  by  faulty  handling*  Consequently,  ve  have 
to  delete  the  driving  operations  from  the  specification  of  the 
private  pool*  They  are  part  of  the  granted  object  rather  than 
1  he  pool  manager*  The  implementation  is! 

^jrj>e  privatepool  =  manager  of  element;  resource; 
begin 

v^r  pool;  a  rray  unitid  of  resource; 
un  it;  uni  tl  d; 
free;  power  set  of  unitid; 
nofree;  condition; 

E!19.e.  net; 
beg  i  n 

i  f  f  r  ee=  ni  1  ^hen  nofree*  wait; 
unit  ;=  oneof(free); 
free  ;=  free— (unit); 
b i nd ( poo  1 [ un it]); 
e  rid  ge  t  ; 
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|jroc  put; 
beg  i  n 

for  unit:=l  ±o  uni tc ount 

whi le  eleraent^pool  ( uni 1 1  do  skip ; 
release; 

free  :=  freeU(unit); 
nof r  ee • 3 1 gna 1 ; 
end  put; 

b  eg  i  n 

free  Z-  allunits; 

for  unit:  =  l  Jto  unitcount  do  ^nl,t  poolCunlt]; 
ejid  ; 

end  private pool; 

In  one  respect*  the  semantics  of  the  manager  are  too 
restrictive  for  the  given  pool  specifications:  every  process  may 
only  possess  at  most  one  resource  object  in  the  pool  represented 
by  some  object  of  type  privatepool*  Therefore*  the  precondition 
of  get  has  to  be  strengthened: 

getvore:  R  (caller)=() 

i  n  us  e 

Again*  a  few  not  obvious  axioms  will  be  used: 

a)  The  following  rule  for  the  f or- wh i  1  e  loop  requires  that 
the  iteration  index  x  is  known  outside  the  loop* 

”xe[a**b]  A  P(  (  a*  .x-l  ])  a  B”  S  ”P  (  [  a*  •  x  ]  )  " 

«p([  ])  II 

for  x:=a  to  b  while  B  do  S; 

”(xc(a**b]  A  P([a**x-1])  A  -»B)  v  (x/[a**b]  a  P([a**b]))” 

b)  ”  A  owner[l  l^caller  a  owne  r  (  arg  )  =  ni  1  ** 

ieunitid 

bind ( arg ) ; 

” owne  r ( a  rg )=caller” 

Note  that  the  bind  procedure  only  corresponds  to  the  part 
of  the  hind  function  in  [ SKB77 ]  that  assumes 
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en t ry _ho 1 d_c oun t- 0 •  The  precondition  ensures  that  the 
c  a  1  1  i  ng  process  ri  oe  «  not  already  access  the  pool* 

c)  ”owner{<lmp  par> ) = ca 1 1 er ” 
r  e  1  e  as  e  ; 

**owner(<imp  par>)  =  nil” 

<imp  par>  is  the  iaiplicit  parameter  described  in  [  SKB77], 
element  f  in  our  case* 

d)  Initially!  owner=nil* 

The  last  three  axi oms  will  be  motivated  in  the  next  section* 


The  former  array  owner  is  now  a 
set  of  pr  ocess— i  cl*  s  t  and  plays  the  role 
introduced  in  the  previous  section* 
function  b ec o me s ! 


function,  defined  on  the 
of  a  hidden  variable  as 
Hence,  the  abstraction 


R  =  Fl  free, owner) 


w  here 

R  5  f  1  I  i  f  ^  owner(pool[i])  =  nil) 

f  ree 

R  “(iji/freea  owne  r  (  pool  [  1  1  )^ni  11 

i  nuse 

R  (call er )  -  ( 1 |  I / free  a  owne  r ( poo 1(  i  )  )  =  caller) 

i  nuse 

The  invariant  is 


T 


A  (iefree  <=  >  owner(pooi[i  ])=nil  ) 

i  run  i  ti  d 

A  0<|  fr  ee  I  <un  it  coun  t 
A  (  ow ner(  pool  (i  ])=caller  -> 

A  o wn er { poo  1  [  J ]  ) f ca 1 1 e r ) 

J^i 


The  last 
of  the  ma 
process* 
most  one 


term  In  the  invariant  states  the  semantic  restriction 

nager  to  tyrant  at  most  one  object  at  a  time  to  a  fixed 

That  Is,  R  (caller)  contains  for  every  caller  at 

i  nuse 


e lement • 


We  proceed  with  the  proof  of  the  manager  proced\ires,  using 
Owickl’s  axioms  for  condition  queue  handling  (see  section  2*1): 
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ELoc  get; 

"I  A  A  owne  r(  pool  £l  ])  ttcal  ler”  (^ollo«rs  from  get.pre) 

1 €  uni t i d 

i_f  f  ree  =  ni  I  then  ”1  a  free=()** 

no  free  •  wal  t ; 

”  T  A  f  ree^  0  ” 

” T  A  f reef  ( ) ” 

uni t  :=  oneof ( free) ; 

"I  A  unitefree" 
fr**e  ;=  free-  (unit)  ; 

”unlt/freo  a  owner ( pool [ uni t ])= ni 1 

A  A  owne  r(  pool  [1  l)fcal  ler” 

1 € un it  id 

b i nd ( poo l[unlt)); 

'*  I  A  owner  (  poo  I  (  uni  t  ]  )  =call  er '*  (implies  get*  post) 

end  get ; 


proc  put; 
heg_in 

'*  I  A  owner(  elemen  t )  =cal  ler”  (follows  from  put.pre) 

XEL  wnlt:  =  l  to  unit  count 

wh  i  le  ele  me  n  tf  poo  I  (  iMi  1 1  ] 

do  "unlteunitid  a  a  elementf  poo  1(  i  ] 

let  1#* unit  — I  ] 

A  el eme nt f pool [ uni t 1 ” 


ski_p; 

'*  A  e  leme nt  f  poo  1  [  i  ]  ” 

i  r  [  1  •  •  un  it) 

’•  I  A  (uniteunltld  a 

A  el emen tf pool ( 1 )  a  e I emen t=po ol ( un i t ] )  v 

ie(l**unit-l] 

(unit/unitld  a  a  e  le  me  n  tf  poo  1[  i  ]  ) '*  (♦) 

i  e [  1*  *001100001 ] 

"I  A  A  e  lement  fpoo  1[  i  ]  a  e  le  me  nt  =  poo  It  un  i  t  )  ” 

let l**anlt“l  ] 

"I  A  ow ner( pool t uni t ] ) = ca 11 er ” 
r e I  ease  ; 

”unit^free  a  owne r ( poo 1 t uni t ])= nl 1” 


free  :=  freeUtunlt) 
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'*  T  A  unitefree” 
no:f  ree«  s  ignai  ; 

”I  A  owner!  elemen  t)  ^cal  ler**  (ImplleB  pat.post) 

end  put ; 

Note  that  the  term  after  the  v  In  the  postcondition  of  the 
f or— wh  1  le  loopy  marked  (t)y  is  false  by  the  capability  handling 
o  f  ma  na  ge  r  s  • 


This  is  the  end  of  our  development  of  private  pool 
implementations*  In  our  first  attempt  we  used  a  very  powerful 
concepty  the  general  shared  class*  The  constraints  of  its 
synchronization  schemey  the  semaphore  y  and  difficulties  because 
of  too  fine  concurrency  lead  to  overcomplicated  assertions  In 
the  proof*  We  found  that  the  common  specification  of  a  resource 
pool  is  too  strong  for  this  implementation  andy  in  generaiy 
postulates  too  much* 


Introducing  a  higher— level  synchronization  concepty  the 
path  exoressiony  resolved  all  these  problems*  Stilly  the  shared 
classy  with  whatever  synchronization  schemey  Joins 

administrative  and  driving  operations  on  the  pool*  The  callers 
have  some  responsibility  in  not  touching  the  resource 
identifications  that  are  handed  to  them  as  ••tickets”  for  the 
resource  grant* 

The  manager  data  type  only  encompasses  the  pool 
administration  and  hands  the  granted  resource  to  the  caller* 
Using  the  manager  again  simplifies  verification*  The 

non-interference  argument  is  entirely  superfluous* 


This  section  exempli 
o  roper  development  of 
with  specifications  that 
one  tries  to  find  the  ■ 
abstract  structure*  A  ma 
concrete  object  has  to 


f i es  better  than  the  las 
an  abstract  data  structure* 
comprise  all  desired  proper! 
ost  appropriate  implementati 
pping  between  the  abstrac 
show  that  really  all  desired 


t  one  the 

One  starts 
ies*  Then 
on  f  or  t  ha  t 
t  and  the 

pro  pert ies 


are  met 
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4. 3 


i a  1  Correc  tnesa  Proofs 


2i  Managers 
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In  the  last  section*  an  example  motivated  the  usefulness  of 
he  abstract  data  type  manager  and  intuitively  introduced  its 
roof  rules*  Vow  we  shall  develop  them  in  more  generality  and 
orma  1  i t  y • 

The  manager  acts  very  similarly  to  the  monitor* 
perations  are  mutual  exclusive*  and  synchronization  of 
ccessors  is  provided  by  wait  and  signal  on  condition  que 
onsequently,  the  axioms  for  the  manager's  Invariant*  ini 
tatement*  and  procedure  bodies  are  exactly  the  same  as  for 
on i tor  • 

However*  additional  proof  rules  have  to  define  the  dynamic 
1  location  by  managers:  the  treatment  of  capabilities*  We 
equire  that  capabilities  are  only  updated  by  the  standard 
perations  bind  and  release*  much  as  condition  queues  by  wait 
nd  slqnal*  Therefore*  bind  and  release  are  defined  more 
enerally  than  in  [ SKB77 ]  where  they  are  only  used  for  private 
ut  not  for  shared  resource  allocation* 

e  consider  the  abstract  data  type 

allocator  =  manager  of  capability:  resource!*** 

nslde  this  manager*  an  object  of  type  resource  appears  as 
hough  it  were  defined  as 

Pe  source  =  re  cord  instance:  resource! 

c apab il i tyse t :  fiowerset  of  process! d! 

end ! 

he  capa b i 1 i tyse t  contains  all  id's  of  processes  that  possess  a 


apab  1  1 

i  t  y  to 

the 

resource  object*  For  private 

resources 

it 

i  s 

1 1  h  er 

empty 

o  r 

contains  one  process*  We 

def i ne 

the 

two 

Its 
its 
ues* 
t  ial 
t  he 


p  roc  edur es 
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eroc  bl  nd  (  Ob  Jec  t  :  resource); 

bggl  n 

i,f  capaiblli  ty=nl_l_  then 
beg^n 

EJLUi  objec  t 

do  c apabl 11 tyset  :=  capabl 11 tyae t U [c al 1 er) ; 
capability  :=  object; 
end  ; 
end  b i nd ; 

pr  oc  release; 
begin 

i  f  capabi  li  ty^^n  i  1  then 
b  egl_n 

capability  do 

do  c apab i 1 i tyse t  :=  capabi 1 i tyse t— [c al 1 e r) ; 
capabi  li  ty  :=  nl.1.; 

e  nd ; 

end  release; 

The  capability  is  an  example  of  a  privafe  program  variable  (of 
type  resource)  that  is  not  auxiliary*  Every  process  has  its  own 
Incarnation  that  Is  only  updated  on  its  request*  and  all 
Incarnations  are  handled  similarly*  Initially*  all  capabilities 
and  capabi  1  i  tyse  ts  are  nil*  We  decided  to  implement  bind  as  a 
procedure  rather  than  a  function  (as  done  in  [SKR77])*  because 
this  seems  to  be  a  more  natural  concept* 

Now*  the  general  proof  rules  for  the  two  operations  can  be 
understood : 

” c  apab i I  ity[  caller  )  t objec  t ” 
bi nd ( objec  t )  ; 

**c  apab  illtyCca  1  ler]  =  objec  t  ” 

”  c  apab  i  1  Ityfcal  ler  ]  =  objec  t  ** 
r  e 1 eas  e ; 

’*capah  1  1  ity[ca  Her  ]=ni  1” 
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We  require  that  capabilities  and  capabi  i  i  ty  se  ts  are  not  updated 
outside  bind  and  release*  Then  the  foilowinK  assertions  are 
p  reserved  I 

I ( capab i ii ty )  - 

A  (  capabi  1  i  ty[  i  ]=  ni  1  <=>  a  i /r  .capabi  1  i  tys  et  ) 

leprocessid  ref? 

A  A  (  capabi  1  i  ty  (  i  ] ^  ni  i  <=  >  (  ca  pabi  li  ty  [  i  ]  =  x  a 

leprocessid  xeR 

i e X • capa bi 1 1 tyse t  a  a  i /r* c apab i 1 i t yse t ) ) 

reR- (x) 

T (capabil Ity)  expresses  that*  at  any  point  of  time*  every 
process  nay  possess  at  most  one  capability*  It  is  part  of  the 
manager  invariant*  since  it  is  true  after  in  1 1 1  a  Xlasa  ti  on  of  ail 
capabilities  to  nil*  I ( c apab I 1 1 t y)  enables  an  alternative  use 
of  the  capability  or  capabi  1  i  tyse  t  variable  in  assertions* 

For  private  resource  management*  the  rule  for  bind  has  to 
be  stroneerl 

**  c  apab  i  1  1 1  y  [  ca  11  er  ]=  ni  1  a  object  *c  apabl  11  tyset=ni  1  ” 

blnd(objec  t)  ; 

**c  apab  i  lityCca  1  lcr]  =  ob  Jec  t  ” 

Tt  Implies*  together  with  T ( c apab i 1 i ty ) *  that  capab i i 1 tyse ts 
contain  at  most  one  process*  The  capabi li tyset  is  a  hidden 
proof  variable*  in  this  case*  in  fact*  a  function  corresponding 
to  the  intuitively  Introduced  owner  function  in  the  private  pool 
example  (see  previous  section)* 

Note  that*  by  generalising  the  binding  scheme*  bind  is  less 
powerful  than  in  [ SKB77  ]*  There*  it  was  Introduced  specifically 
to  ensure  a  proper  distribution  of  private  resources*  Here*  it 
handles  resource  distribution  in  seneral*  and  only  an  especially 
strong  precondition  guarantees  that  private  resources  remain 
p  r I va  t e  * 

Assertions  about  the  resource  objects  (private  or  shared) 
are  handled  like  assertions  about  shared  abstract  data  types* 
only  that  for  the  caller*  unless  it  is  the  manager*  the  anabling 
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p  rertl ca  te 


capabl  1 1 1  jr  [  c alien  ]=  ob  Jec  t 


has  t  o  ho  1  rt • 


As  i 1  lustra 1 1  on »  let  us  modify  the  pool  specifications  to 
suit  the  allocation  of  shared  resources  and  implement  it  by  a 
m ana^er • 


shared  pool Z 

Req  : 

Inlt  : 

T : 


R  “  u  (r  ) 

i  r  un  i  t  i  d  i 


true 


P  =  [)  A  R  =  U  (r  ) 

inuse  free  icunitid  i 


A  A  r  initialized 
r  rP 

R  =  R  UR  A 

1  nuse  free 

R  =  U  R  ( ca I  1 er ) 

inuse  cal lereproc essid  inuse 


Operations:  get(r) 

pre:  IreR  ^  r=undef )  a  R  (caller)=() 

i  nuse 

post:  rcR  =>  (R*  —R  *  P*  -R  » 

inuse  inuse  free  free 

R*  (caller)  =  Cr)  ) 

1  nuse 

r=undef  =>  (r*=Xf  R*  =R  ”  ( x)  t 

xeR  free  free 

P  •  {  cal  1  er  )  =  Cx  )  ) 

inuse 


put(  r) 

pre:  R  (caller)  =  (r) 

i  nuse 

post:  R*  (caller)=() 


1  nuse 

- 

N  o  te 

that  R  does  not  anymore  form  a  distinct 

1  nuse 

union 

of 

t  he 

R 

(i)  over  i  in  proc  essid.  The  postcondition 

of 

put 

is 

I  nus  e 


attain  weakly  specified*  An  additional  requirement 


(a  r /R 

1  epr  ocess  irt 
1 ^cal ler 


(  1) )  => 
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i  nuse 

(R*  =R  -(r)  ,  R»  =R  U  (r)  ) 

louse  louse  free  free 

t  haf  the  resource  r  Is  made  available  If  "the  caller  vas  Its  onljr 

owner  could  cause  interference  probless  In  the  caller  proof* 

Since  in  the  shared  pool  the  resource  objects  are 

t 

d  i  s  t  inia;ui  shah  1  Of  the  precondition  of  put  has  to  be  sore  specific 
than  in  the  private  pool*  Note  that  our  first  private  pool 
Implementations  also  made  the  objects  distinguishable  for  the 
competitors  (by  an  explicitly  passed  id  parameter)*  This  «Miy  be 
desirable  y  e*ij;*9  for  message  passlngt  but  Is  not  a  requirement 
for  the  general  specifications* 

The  manager  implementation  followsi 

const  undef  =  0; 

^J^£e  ext_unitid  =  unde  f*  •  uni  tc  oun  t  ; 

type  sharedpool  =  S?2,£13Lfi®E  Sl  element  I  resource! 
begi.  11 

var  pool:  array  uni  tld  of  resource! 
uni  t:  uni  tld! 
free:  B2.E.SE®®!  uni  tld! 

nofreet  condition! 

j>roc  get  (var  id:  ext_unltid)! 
begl  n 

1 f  id= undef  ^hen 
begl  n 

i f  free=n^l  then  nofree*wait! 
id  :=  oneof(free)! 

EQ-Sl  • 

i_f  idefree  tl^n  free  :=  free— (Id)  ! 
b 1 nd ( poo  1 [ 1 d  ] )  ! 
end  get  ! 
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proc  pu  t ; 
beg  i  n 

for  unl'tl  =  l  unltcount 

wh i 1 e  el ement^pool [ uni t ]  skip ; 

release* 

pool[  unit ]• capabi 1 i tyset^ ni I  then 
begin 

free  :=  freeLI(unit)  ; 
nof  ree • si gnal ; 
end  ; 

end  put ; 
begin 

free  1=  allunitej 

for  unit:  =  l  to  anitcount  do  i  ni  t  pooI[unit]; 
end ; 

end  shared pool; 

Fhe  abstraction  function  is 


R  =  F {free* pool) 


where 

R  5.  (ijiefree  a  pool(  1  ]  •capablll  tyset  =ol  1  ) 

free 

R  ^  (iji^free  a  poo  1[  i  ]  •capabi  1  i  tyset^ni  1 ) 

i  nuse 

R  (caller)  «  Ci|l/free  a  callerepooK  i  )•  capabi  li  tyset) 

1  nuse 

R  (caller)  contains  for  every  caller  at  most  one  element* 

inuse 

The  Invariant  is 

I  -  A  (irfree  <=>  pool ( 1 ]• capabi 11 tyse t=n i 1 ) 

ir  un 1 tld 

A  0^1  f  r  ee  I  <unltcount 
A  I ( element ) 


The  proof  of  get! 
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gg  t  {  va  r  i  d  t  ex't_unl  tid)  ; 

be  gi  n 

”I  A  e  lenen  t[  cat  Her  ]=nll  (follows  from  get.pre) 

A  Ideext _unl tld" 
if  ld=undef  then 


begin 

"I 

A 

i  d=undef  ** 

it 

free=nl_^  ”i  ^  free=()” 

nof  ree*  wai t ; 

”  T 

A 

ld=undef  A  free^O** 

i  d 

•  ^ 

•  — » 

oneof  (  free  )  ; 

”1 

A 

idefree  a  ideunltid” 

end ; 

”T  A  id€unltld” 

idefree  then  ”I  a  Idefree” 

free  Z-  free— (id)  ; 

”  id/free  a  ele men t[  ca  1 1  er  ]=n i  1 '* 
blnd(pooir  Id)  )  ; 

”  I  A  e  I  emen  t  [  call  er  ]=pooJ(ld*]  a  F(ld)'*  (i  mpll  e  s  get*  po  st ) 
en  d  get ; 

where  F(id)  relates  the  input  and  output  state  of  the  parameter 
i  d  as  to  1 1 ows ! 

F(ld)  £  (ideunltid  =>  id»=id) 

A  (id=uodef  =>  (id’efree  a  f  ree  •  =f  ree— (1  d*  }  )  ) 


The  proof  of  put; 
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(follows  fot»M  puf«pre) 


pr pc  put; 
begin 

A  elenentt  c& Her  l#nl  1  ” 
for  unlt;=l  to  unit count 
wh^^o  elenie  nt^pool[  uni  t  ] 
rfo  ”unl  teuni  tid 

^  ^  pleraent [caller  l^pooll 1 1 

i e  [  1 • • un it-1  ] 

A  el  enent  [  cal  1  er  l^pool  I  uni  t  ]  ** 

”  ^  ele sent  [cal ler  ]^poo  1  £  i  ]  •• 

i  r (  1 • • un it] 

”T  A  (unite  unit  id  a 

A  elenent [caller  ]^pool[ i ]  a 

i e [ 1 • • uni t— I ] 

el  enent  [  ca  Her  ]=pool  [uni  t  ]  )  v  (unit/unitid  a 


lr[ l*«unit  coun  t ] 


el  eaen  t  [  ca  Her  ]^  pool  [  i  ])" 


•I 


I  A 


A  eleaent  (caller  ]#pool[  i  ] 

i  r (  1  • • un i t  —  1 ) 


A  element  [  caller  J  =  pool  [uni  t  ]  *• 
rel  ease  ; 

"unit/free  a  ei  eraen  t[  ca  1  i  er  ]=nl  1*' 

pooi  (  uni  t  ]  •  capab  i  I  i  t  yset  =ni  i  then 
begin 

free  :=  freeU(unit}; 

”T  A  unltefree  a  eleae  nt  [ca  Her  ]  =  n  i  I  ** 
no  free •signal; 
end ; 


(♦) 


”I  A  eiement( ca 1 ler  l=ni 1” 
end  put  ; 


(iraplies  piit«post) 


The  f  or— wh  i  le  axiom  has  been  introduced  in  the  previous  section* 
Here*  more  forraaliy  than  in  the  proof  there*  the  term  after  the 
^  in  the  postcondition  of  the  f or— whi le  loop*  narked  (♦)*  Is 
faise  by  the  validity  of  T(eleaent)  In  !• 
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4.4  Teriinat  i  on  Prop  fa  ot  Cal,ls 

to  Sha red  Abatrac  t  Data  Ob  Jec  t a 

The  previous  proot  outlines  for  the  semaphore  and  the 

resource  pool  only  argue  the  partial  correctness  of  their 
i mol eraent at  Ions •  Termination  has  to  be  shown  separately* 

This  section  Illustrates  termination  arguments  for 
operations  on  shared  abstract  data  t3rpe3»  We  shall  not  be 
looking  at  the  termination  of  sequential  statements*  This 
matter  receives  consideration  in  a  number  of  publ ica t Ions t  eag«t 
[Man?  4,  KaMa7  5,  MaWa78]* 

Our  concern  is  to  derive  conditions  under  which  the 

synchronization  of  operations  on  some  abstract  data  object 
cannot  lead  to  non  — termlna  ti  on  of  the  call  statement  in  the 
calling  process*  AgaiOf  the  proof  technique  follows  closely 
that  of  [Owi77b]*  We  assume  that  the  only  cause  for  a  process 
delay  is  synchronization  on  some  abstract  data  object*  Effects 
of  system  scheduling  are  not  regarded* 

The  notation  A-*B  indicates  that  a  computation  is  bound  to 
eventually  reach  state  B  if  it  reaches  state  A  at  some  point* 
We  shall  use  expressions  like 

/  A  -•  B  aC 

which  expresses  that  state  A  is  followed  by  the  validity  of  B 

and  C*  Nothing  is  said  about  the  length  of  time  that  B  and  C 

hold*  But  there  Is  some  point  after  A  occurred  at  which  both  B 
and  r  are  true* 

The  following  predicates  are  of  Importance  in  termination 


p  roo  f  s  T 
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start ( 1 ,L) : 

process  i  Is  about  to  execute  statement  L* 
f inish( IfL) : 

process  i  Just  finished  the  execution  of  stateaent  L* 
hi ocked(  1 t  L)  t 

process  1  Is  delayed  in  the  execution  of  stateaent  L* 

Fvery  1 anKuafi^e  stateaent  Is  characterized  by  an  axiom  that 
defines  Its  pre—  and  postcondition  for  termina tlon f  very 
similarly  to  Its  partial  correctness  axiom*  The  termination 
axiom  has  the  formt 

termination  condition 

LI  statement;  - 

termination  expression 

If  the  termination  condition  can  be  shown*  the  stateaent 
terminates  according  to  the  stated  termination  expression* 
Owickl*s  termination  axiom  for  the  concurrent  statement  is  only 
suitable  for  the  trivial  case  of  disjoint  processes  (no 
interaction  through  synchronization  or  access  of  shared  data 
[HoaTS]); 

L:  cobegin  Si //*•*// Sn  coend; 
n 

A  start(i*Si)  -♦  finish(ifSi) 

i  =  l 

(  s  tart  (  0*  L  )  Apr  e  (  L)  )  -•  (f  i  n  ish  (  0*  L)  Apost  (  L)  ) 

The  termination  axioms  for  the  sequential  statements  in  our 

examples  are  fairly  straight-forward  and  will  not  be  given  here* 
We  only  use  loops  that  are  bound  to  terminate*  for  loops*  For 
the  axiom  of  the  ldi_il_e  loop  see  [OwGr76a]* 

Let  us  now  start  with  the  investigation  of  shared  abstract 

data  types*  The  termination  of  any  syncbronlzed  operation 
T*p(x;y)  is  expressed  by  its  delay  as  sc  r  1 1 o  n • 

(blocked(caller*T.p(i;y)  )AT.p. Delay)  -  ^T*p*Delay)  => 

(  start(call  er*T*p  (x;y)  )  f  In  1  sh  (  ca  1 1  er  *T.  p  (  x  *  y  )  )  ) 
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r*r»*Delay  is  a  condition  that  has  to  be  proven  nec 
n on- t erral natl on  of  procedure  T«pf  the  delay  condit 
(T«p*T)elay  need  not  necessarily  be  the  negation 
resumption  condition  in  the  proof  of  T*p  hut  must  imp 
the  delay  assertion  holds  with  a  proper  delay  cond 
procediire  call  in  process  1  is  axiomatized 

l:  T*  p(  ay  e  ) ; 

(  b  ]  oc  ked  t  1 1  L)  Apre  (  L  )  aT»  p  •  De  lay  )  -iT^p^De 


(start(  IfL)  Apre  (L))  -•  (finish(itL}  a  post  (  L)  aT«p  •pos 
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n* 

[  Owi 

77b  ] 

s 

ta 

te 

s 

th 

e 

the  partial  correct 
ses  that  9  while  1  is 
OQdition  must  eventu 
s  convenient  to  assu 
data  type  T  is  f 
may  postpone  the  re 
nt  of  time  after 
termination  conditio 


(  s  t  ar  t  (  i  9  L  )  Apre  (  L )  AT  •p  •  De  1  ay )  -•  -tTcpaDelay 
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(general  shared  class: 

LI  :  sera*P; 

(  bl  ocked  (  ca  1 1  er  9  LI  )  Apre  (  Ll  )  Asera^O  )  -*■  sen>0 

{  s^ar-t  (  cal  ler  9  Ll  )  Apre(  Ll  )  )  -•  (  f  1  ni  sh  (  cal  ler9Ll  )  Apo  st  (  L  1  )  ) 

L2 :  sem • V ; 

(  s  tar  t  (  cal  ler  9  L2  )  Apre(  L2  )  )  -•  (  f  1  ni  sh (  cal le  rt  L2  )  a po  st  (  L  2  )  ) 

Note  that  seni«V  terminates  unconditionally* 

The  termination  postcondition  is  more  explicit  than  the 
partial  correctness  post c o nd i t ion  9  because  It  nay  Include 
variant  assertions  that  do  not  hold  as  precondition  of  the  next 
statement*  In  this  case9 

post(Ll)  5  (sem*  =raax ( 0  9  sem-l  )  ) 
and  post(L2)  —  (sem*=sem+l) 

are  not  I nterference- f ree  in  the  partial  correctness  proof* 
They  are  valid  immediately  a tt er  the  termination  of  Lt  and  L2 
r  espec  t  i  ve  1  y  9  but  need  not  remain  invarlantly  true  until  the 
execution  of  the  following  statement  (see  section  4*2 )• 


FlnaJly9  let  us  define  axioms  for  the  even  lorer— level 
synchronization  scheme  of  manas^rs  and  moni tors9  cnndition 
queues*  Heret  we  have  the  choice  between  different  partial 
correctness  rules9  and  the  termination  axioms  look  different9 

w 

accor  diner  1  y*  Agaln9  the  superscript  Indicates  the 

substitution  of  cond*len4'l  for  cond*len9  whereas  the  subscript 

♦ 

expresses  the  substitution  of  cond*len—l  for  cond*len* 
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!•  Followiniei  (Owl77«.] 

Partial  correctness! 

«  *  * 

”PaI  w  condtvwait  "Pa  I  aB  (cond)" 

"  Pa  I  aB(  cond  )  "  cond«sienal  "PaI" 
wrher  e 

B(cond)  =>  -*cond*empty 
Termination : 

T-l!  cond  .wait; 

(bl  ocked{  call  er  t  L 1 )  Apre  (  Ll  )  a-»B  ( c  ond)  ) 

♦ 

-►  (post  (  Ll )  A  atar  t  (  J  f  L2  )  ) 

_ ♦ _ 

(  startfcallert  Ll  )  Apre  (Ll)  a-^R  (cond  )  ) 

•*  (  f  i  n  Ish  (  cal  le  rf  Ll  )  A  post  (  Ll )  ) 


L2:  cond^si^nai; 

(  star  t  (  cal  ler»L2)Apre(I.2)  )  -•  (flni8h(callerv  L2 )  Apo3t(L2  )  ) 
2«  Following  [Hoi»76b] 

Partial  correctness! 

t  ♦  ♦  ♦ 

"PaJ  aE  "  condawait  "PaJ  aB  (cond)" 

"  Pa  JaR(  cond  )  "  condasignal  "PaJaE" 
wh  ere 

B(cond)  =>  conclalen>0 
and  JaF  =>  -»B(cond) 
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Term! nation! 


1,1  ;  con<l««ra  it; 

( bl ocked( oal ler, Ll ) Apre  (Ll))  -  (post  ( Ll ) Astart ( J , L2 ) ) 
_ ♦ _ t _ 

(  sta  r  t  (  ca  1 1  c  r  t  L 1  )  Apre  (  L 1 )  )  -•  (  f  ini sh  (  ca  1 1  er  t  L 1  )  Apo^i  t  (  Ll  )  ) 
L2  :  c  ond*  sif^na  I ; 

(  start!  caller,  L2)  Apre  (  L2)  )  -  (  f  inish(  ca  Her ,  L2  )  Apos  t(  L2  )  ) 

In  both  cases,  the  termination  axioms  express  the  same,  only  in 
the  first  case  they  have  to  compensate  the  weaknesses  of  the 
partial  correctness  axioms*  The  influence  of  signal  on  the 
termination  of  wait  has  to  be  explicitly  stated,  since  the 
synchronization  scheme  permits  resumption  conditions  to  remain 
u  ns  i|2na  1  led*  It  is  important  to  realize  that  the  consideration 
of  queue  lenpths  is  essential  for  termination  arjeuments  in 
abstract  data  types  with  condition  queue  synchronization* 
Therefore,  Owlcki’s  partial  correctness  rules  have  been  extended 
accordlnely* 

The  termination  of  bind  and  release  in  the  Banap:er  is 
defined  by  the  trivial  termination  axiom! 

L!  bi nd ( object ) ;  or  L!  release; 

(  s  ta  r  t  (  cal  1  er  ,  1  )  Apre  (  L  )  )  (  f  1  nl  sh  (  cal  1  er,  L)  a  pos  t  (  L  )  ) 


We  are  now  able  to 
semaphore  and  resource 
s  ec  1 1 ons  * 


prove  the  termination  for  some  of  our 
pool  implementations  in  the  previous 


1*  semaphore  monitor 


a)  semaphore*?; 

seraa  phore*  r*  *  Pe  1  ay  !  s=0 

(If  s>n ,  P  trivially  terminates* 
s  =  0  =>  -•P(q)f  the  negated  resumption  condition*) 

The  termination  of  P  requires  its  delay  assertion 
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(i)  (  (  blockedC  cal  ler  *  P)  As=0  )  -•  a>0)  => 

(  st  ar  t{  ca  1 1  er  f  P  )  -•  f  i  nlsh(  cal  le  rt  P)  ) 

The  only  problen  in  this  implication  is  the  termination  of 


l:  q«wait; 

in  P*  We  have  to  show 

(il)  (  bl  oc  ked(  ca  11  er  t  L)  A  pre  (L))  -♦ 

a 

(post  ( L) AS tart ( J yq« 9 iena 1 ) ) 

a 

The  following  holds: 


pre  (L)  =>  (I  A  s=0  a  q»len>0) 

a 

The  only  operation  that  cant  incrementing  Sf  validate 

P{q)  and  hence  post  (L)  is  V.  Doinii;  sof  it  Is  bound  to 

a 

execute  signaly  which  verifies  (11)* 

The  presumption  in  the  delay  assertion  implies  the 
execution  of  signal  which  verifies  (i)« 

Proving  that  a  call  to  P  does  terminate  means  proving 
the  presumption  in  the  delay  assertion  for  P: 

(  blocked!  cal  leTf  P)  a  8=0)  -•  s>0 


One  has  to  argue  that  some  other  process  in  the  system 
must  eventually  execute  Vf  if  8  =  0  and  the  caller  is  still 
blocked*  In  our  case  this  holds  because  of  the  infinite 
loop  structure  of  the  processes* 

h)  semaphore* V; 

semaphore* V • De 1  ay :  false 

(V  is  not  synchronized*) 

V*s  delay  assertion  is 

(  (blocked!  ca  Her, V)Afalse)  -  -tfalse)  => 

( start ( caller, V)  -  f Inish ( ca 1 1 er , V) ) 


or  si  rap J  y 
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startical  lertV)  -  f  i  nl  ah  (cal  iert  V) 

2«  nrlvatepool  mana§(er 

a)  pr 1 vatepool • set ( id) ; 

prl  va  te  poo  1  •  (7e  t  •  Delay  :  free  =  nii 

(free=nil  =>  -«B(nofree)f  the  negated  reauaption 

cond i t Ion* ) 

^et  has  the  delay  assertion 

(i)  {(blockedCcal  Iert  pet ) a  free=  nil)  ^  t ree^ni  1 )  => 

(  st  ar  t (  ca  11  er  f  get  )  f  1  n i  8h(  c a  1  le  pe  t )  ) 

The  only  problem  in  this  iraplicatlon  is  the  teraination  of 

LI  nofree*wait; 

in  pet*  Wo  have  to  show 

(li  )  {  b  1  oc  ked(  cal  1  er  »  L  )  Apr  e  (L))  -♦ 

♦ 

(post  ( L ) AS t  ar  t{J»nofree*3l gna 1 )  ) 

1 1  holds 

pre  (L)  =>  (I  A  free=nll  a  nof  ree  •  1  en>  0 ) 

* 

The  only  operation  that  cant  by  inserting  in  free, 

validate  B(nofree)  and  hence  post  (L)  is  release*  Doing 

♦ 

so,  it  is  bound  to  execute  signal  which  verifies  (ii)* 

The  presumption  in  the  delay  assertion  implies  the 
execution  of  signal  which  verifies  (i)* 

Proving  that  a  call  to  get  terminates,  as  before, 
means  arguing  that  release  must  eventually  be  executed  if 
the  free  set  Is  empty  and  some  process  is  wai  ti  ng*^ 

b)  pr i va te pool  *  put J 

pr i va t e poo I  *pu t * Del  ay  I  false 

(put  is  not  synchronized*) 


78 


Th«»  dteLay  assertion  1  «f  unc ondl  tionnl Ijr 

start(callerf  put  )  -•  f  i  ni  sh  (  c  al  ler  f  pu  t ) 

3*  sharertpool  nanaper 

Exactly  like  2*t  the  prlvatepool  manager* 

4*  prlvatepool  general  shared  class 

The  proof  is  very  similar  to  the  previous  example  and  is 
outlined  in  [Owi77b]*  Validation  of  the  delay  assertion  for 
get  is  deduced  from  the  invariant 

freecount  =  Jfree|tb“a 

S*  prlvatepool  path  expression  class 

a)  pri vat epoo 1 •get < uni t ) ; 
prlvatepool  *00!  .Be  lay  I 

C  ^  (#(get)-#(  put )  >  uni  tc  oun  t ) 

(from  the  path  expression) 

The  delay  assertion 

(  (  b  1  oc ked (  ca  1  I er  f  ge  t  )  aC  )  -*  -»C  )  => 

(  s  tart  (  cal  le  r*  ge  t )  -•  finish!  ca  Her  t  get )  ) 

is  enforced^  by  the  path  expression*  Its  presumption  is 
verified  as  above* 

b)  pr i vatepoo 1 *put ; 

pri va  te  pool  *put  *  Del ay  I 

C  5  ( # ( get  )  — #( put )  <  0) 

(from  the  path  expression) 

The  delay  assertion 

(  (  bl  ocked(  ca  1 1  er  »  put  )  aC)  -•  -*0  => 

(  s  tart  (  cal  1  ery  put )  -•  f  lnlsh(  ca  1  le  r  y  put  )  ) 


79 


is  enlort:ed  by  th«  path  expression*  Its  presumption 
holds*  for  instance*  if  each  process  calls  t  and  put 
every  other  tloie*  starting  with  get* 

Note  that  the  path  expression  synchronizes  put  as  well*  Errors 
due  to  unsynchronized  calls  of  put  in  the  other  1  aipl  emen  ta  t  i  ons 
have  to  be  (and  are)  taken  care  of  in  its  code*  The  termination 
proofs  demonstrate  very  well  the  power  of  path  expressions* 


80 


5  Cone I uai ona 

The  Inve  ati  on  at  verification  technlQues  for  concurrent 

algorithms  motivates  several  language  features  for  the 
structurerf  representation  of  concurrency. 

We  understood  the  suitability  of  the  concurrent  statement 
for  the  representation  of  a  set  of  concurrent  processes.  It 
syntactically  frames  the  concurrent  execution  In  the  program 
text  with  c  ob  egin. . .c  oe  nd  and  (in  the  more  sophisticated 
formats)  defines  the  data  shared  among  processes  by  r eso urc e  or 
s  hared.  This  supports  the  documentation  of  correlations  and 
interferences  between  processes. 

Secondly*  and  above  all*  we  realized  the  significance  of 
shared  abstract  data  types  for  structured  concurrent 
programming.  For  sequential  structured  programming*  principles 
like  stepwise  refinement*  modularity*  and  the  development  of 
program  families  have  been  suggested  [DDH72*  Par76].  Carried 

over  to  concurrent  programming*  the  major  goal  comprising  all 
these  techniques  Is! 

Design  your  concurrent  program  as  a  collection  of  interacting 
processes*  and  keep  the  design  problems  as  much  as  possible 
In  a  sequential  context.  In  another  sfep*  worry  about  their 
Interaction.  ^ 

The  process  serves  much  the  same  purpose  in  concurrent 
programming  as  the  procedure  In  sequential  programming.  The 
design  problem  is  broken  into  parts  that  are  easier  to 
comprehend  and  solve  by  themselves.  The  call  convention  of  the 
procedure  corresponds  to  the  sy nc hron Izat ion  and  interference  of 
processes.  It  is  the  interface  that  specifies  all  communication 
between  the  module  (procedure  or  process)  and  its  environment. 

Shared  abstract  data  types  achieve  the  isolation  of  this 
Interface  from  the  concurrent  program  modules*  the  processes. 
Processes  may  be  designed  without  regard  to  their 
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synchronization  and  Interference*  The  proper  specification  of 
the  communication  device*  the  set  of  shared  abstract  data  types 
for  the  concurrent  statement*  takes  care  of  all  that*  The 
advan ta/^eous  effect  of  this  principle  is  documented  by  the 
verification  requirements:  the  problem  of  non-interference  can 

be  (almost)  entirely  absorbed  in  abstract  data  types*  An 
illustratinj?  argument  for  the  need  for  separating  the  interface 
to  Its  environment  from  the  process  is  that  it  becomes  properly 
specifiable*  Abstract  data  types  are  built  according  to  a 
general  specification  pattern  that  comprises  all  external  and 
Internal  requirements  on  the  defined  data* 

One  need  not  stop  at  this  point*  The  manager  data  type 
indicates  that  abstract  data  types  can  also  represent  different 
kinds  of  specialized  higher- level  communication  between 
processes*  in  this  case  the  competition  for  resources*  Others 
are  conceivable* 

A  still  not  sufficiently  solved  problem  is  deadlock  in 
access  hierarchies  of  shared  abstract  data  types*  The  manager 
provides  a  safe  and  useful  design  tool  for  an  Important  suJ>set 
of  applications*  but  none  of  the  given  data  types  supports  a 
practical  general  technique  for  deadlock  avoidance*  Recent 
issues  of  the  ACM  SIGOPS  Journal  Operating  Systems  Reviews 
contain  a  discussion  on  this  subject*  started  by  [Lls77)*  It 
seems  that  deadlock  avoidance  Imposes  very  strong  requirements 
on  the  integrity  of  shared  data  objects* 

As  It  appears  In  Owlcki's  proof  method*  the 

non-interference  argument  is  the  most  cumbersome  and  problematic 
panf  of  concurrent  correctness  proofs*  It  leads  to  a  proof 
effort  that  grows  non— linearly  with  the  size  of  the  program  and 
possibly  to  a  revision  of  the  previously  developed  sequential 
proofs  for  the  processies  (if  interference  has  been  detected)* 
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two  alternatives  for  the  structured  development  of  concurrent 
programs : 

a)  If  the  nature  of  concurrent  communication  Is  known  with  the 

program  s pec  1 f 1 ca t i on y  the  definition  of  the  shared  abstract 
data  types  Is  possible  or  has  been  done  before  the 

development  of  the  processesy  and  it  can  aid  in  a 

constructive  process  design*  This  will  be  the  approach  for 
concurrent  systems  with  very  simple  or  widely— used 

communication  patternsy  e*g*y  competition  for  resources* 

b)  If  the  nature  of  concurrent  communication  Is  not  documented 
by  the  program  spe ci f 1  cat  1  on y  the  processes  are  constructed 
flrsty  with  calls  to  ficticious  data  type  operations*  Then 
the  specifications  for  the  abstract  data  types  are  deduced  to 
satisfy  all  call  assertions  in  the  different  processesy 
according  to  the  rule  of  consequence*  This  will  be  the  more 
frequent  approachy  for  complex  concurrent  systems* 

In  certain  casesy  a  complete  absorption  of  concurrency  matters 
in  abstract  data  types  may  not  be  possible*  This  is  reflected 
by  the  context  sensitive  ”rul e  of  adaption”y  which  analogously 
also  applies  for  procedures  [Owi77by  Hoa71]*  Without 
restrictions  on  concurrencyy  one  cannot  hope  to  reach  the 
ultimate  goa  1  y  entire  isolation  of  interference  considerations* 
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by  Pa^h  Expre anions 

in  **Operatinff  Ssrsteas***  Lecture  Notes  in 
Computer  Science  16y  Goos  and  Hartmania  (Eds*)* 
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[ Flo67] 


Flont  L*;  Habermannf  A.*N« 

Tor ard3  l.iie  C^nstruct^g  of 
Ver if lab ie  Software  Syatens 

Proc*  2nd  Int*  Conf*  on  Software  En pi neeri n ^9 
13»—15« 10« 1976»  San  Franclscof  Cal«9  141—148 

Habermann  trloR  to  overcome  the  monitor  drawbacks  (see 
entry  [Hoa74])  by  the  followings  change  in  the  concept 
of  an  abstract  data  type  that  represents  shared  data! 
rather  than  providing  mutual  exclusion  and 

synchronization  primitives  for  every  operationy  a 
”path  expression”  defines  the  scheduling  constraints 
(short-term  and  med  iuot- term )  for  the  operations  In 
respect  to  each  other  and  the  state  of  the  data*  It 
has  to  Incorporate  mutual  exclusion  as  well  as  all 
synchronization  conditions*  Thereby  the  calls  to 
operations  are  synchronized  rather  than  their 
execut i ons* 

The  concept  is  exemplified  for  the  bounded  buffer 
and  the  pr  oduc  er  — c  on  sumer  problem*  It  is  argued  that 
the  use  of  path  expressions  not  only  structures  the 
synchronization  on  shared  abstract  data  typeSf  but 
also  facilitates  the  proof  of  synchronization 
prope r 1 1  e  s* 

Kaber«ann*s  abstract  data  type  provides  a  more 
flexible  short- ter*  scheduling  scheme  than  the  monitor 
but  does  not  solve  the  problems  with  deadlocks  in 
access  hierarchies.  The  impacts  of  the  restrictions 
on  synchronization  are  debatable* 

FI  o  yd  ,  R  •  W  * 

Ass igni  ng  Meani ngs  to  Program^ 

Proc*  of  Symposia  in  Applied  Mathematics  19f 
American  Mathematical  Society,  1967,  19-32 
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[  Gr  1 7  6  ] 


[  Gri77  ] 


[  Gr  i  7  8  1 


GrieSf  D« 

An  T I  last  rati  on  oj[  Current  Ideaa  og  Par  ivat  ion 

of  Corree  tnesa  Proofs  and  Correct  Prograea 

lEFE  Trans*  on  Soft*  Eng*  SB— 2f  4  (Dec*  1976) t  238-244 

GrleSf  D* 

An  Exercl^ae  ^n  Pro5ri_ng  Parallel  Prograes  Corree  t 
Comm*  ACM  20,  12  (Pec.  1977),  921-930 

As  a  non— tririal  example  for  a  verification  vith 
Owlcki’s  axiom  system  (  OrCr76a,  OwSr76b),  Cries  proves 
the  correctness  of  the  on— the— fly  garbage  collector 
for  a  LISP  Implementation  by  Dijkstra*  The  concurrent 
environment  consists  of  the  garbage  collector  process 
and  the  communicating  algorithm  (mutator)  the  LISP 
program  has  to  use* 

Since  the  problem  specifies  a  highly  dynamic  set 
of  shared  variables,  the  general  concurrent  statement 
(without  resources)  is  used*  The  two  processes 
collector  and  mutator  are  proven  sequentially  correct 
and  shown  to  be  in t er ferenc e-f ree*  Termination  need 
not  be  verified:  both  processes  run  forever* 

Note:  The  problem  does  not  require  synchronization, 
but  auxiliary  variables  have  to  be  handled  in 
elementary  actions* 

Cries,  D* 

The  St  a  tereent 

IEEE  Trans*  on  Soft*  Eng*  SE- 4,  2  (Mar*  1978),  89-93 

Cries  defines  axioms  for  multiple  assignments  to 
simple  variables,  to  a  single  subscripted  variable, 
and,  as  a  new  contribution,  to  several  subscripted 


varlabi es 


87 


The  axiofli  for  the  multiple  aasliicnment  to  slmpie 
variables  is 

X 1  f  •  •  •  f  xn 

**P  **  xlf««*txn  1=  elf*««yen 

el f • • • f  en 

To  satisfy  these  axiomatic  semanticsy  all  expressions 
el  have  to  be  evaluated  before  any  assignment  to  some 
xi  is  performed* 

The  axiom  for  the  multiple  assignment  to  a  single 
subscripted  variable  in  the  array  b  is 

b 

Mp  ”  b[r]  :=  e  ”P" 

( b ; r :e ) 

where  the  array  (  b;  rZ  e)  is  defined  by 

(b;rJe)llJ  £  If  l  =  r  then  e  el_se  b[l] 

For  several  redefinitions  of  subscripted  variables  in 
by  Gries  defines  the  rule 
b 

**P  '*b[r1]y**yb(rn]:=ely««y  en  '•  P” 

(b^rlZel y««yrn:en) 

which  implicitly  defines  the  order  of  assignmenty 
because  the  ordering  of  the  pairs  rl I ei  affects  the 
semantics*  A  more  general  rule  that  allows 

unrestricted  concurrency  is  mentioned  but  considered 
imprac  t i cal  * 

Example  proofs  are  given  for  an  algorithm 

maintaining  a  linked  list  and  an  array  sort  algorithm* 

Gries  makes  the  point  that  multiple  assignments 
are  easier  to  comprehend  than  equivalent  sequences  of 
simple  assignments*  But  to  understand  and  simplify 
the  precondlt  lony  the  assertion  characterizing  the 
multiple  asslgnmenty  may  require  considerable 

intuition  and  effort  that  may  be  exponential  in  the 
number  of  updates  performed  by  the  multiple 


a  sslgnment 
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[ Hab72 ] 


[  HGLS78] 


[  Hoa6  9] 


[ Hoa7 1 ] 


Uabemannf  A*  N* 

Synchroniza  ti  on  of  Cogmuni^at  Jjtn  Procassea 
Coran.  ACM  15,  3  (Mar.  1972),  171-176 

Habrrnann  defines  the  data  structure  seraaphore  through 
three  counters: 

nw(  s)  the  number  of  attempted  executions  of  ealt(s), 
np( s)  the  number  of  successful  executions  of  #alt(s), 

ns(s)  the  number  of  executions  of  sisnalis). 

The  semaphore  Invariant  Is  defined  as 

npfs)  =  ■ln(nw(s),C(8ltns(s)) 

where  C(  s  ]  is  the  Initial  value  of  the  semaphore  s. 
Implementations  of  the  bounded  buffer  and  a 
producer— consumer  system  are  proven. 

Holt,  R.C.;  Graham,  C.S.;  Lazovska,  E.D.;  Scott,  M. A. 

Structured  Cone urrent  Programmi ng 

with  Ope  ra  ting  Systems  Appl Icatlons 

Add i son-Wesley  Series  In  Computer  Science, 

1978,  262  p. 

Hoar e ,  C.  A.  R. 

A n  Axloraa  tic  Bae_^s  for  Computer  Programming 
Coram.  ACM  12,  10  (Oct.  1969),  576-580,  583 

Hoare,  C.A.R. 

Procedures  and  Eo£Sfieter3:  An  Axj  omatl c  Approac  h 
Syraposluin  on  Semantics  of  Algorithmic  Languages, 
Lecture  Notes  In  Mathematics  188,  Engeler  (Ed.) , 
Springer  Verlag,  1971,  102—116 
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[ Hoa7  2a ] 


[  Hoa7  2b ] 


Hoarey  C«A«R« 

Towards  a  Theory  of  Paralle  I  Prog  rawing 
in  "Opera  ting  Systems  Tec  hn  Iques**  y  Hoare  and  Perrott 
(Eds«)y  A«P«I«C«  Studies  in  Data  Processing  9y 
Academic  Pressy  1972y  61—71 

Hoare  lays  the  foundation  for  the  formal  treatment  of 
concurrent  statements*  The  concurrent  statement  and 
the  notion  of  a  EfiS2iSEE.fi  the  set  of  shared 

variables  associated  with  a  concurrent  statement  are 
introduced*  The  a^th-when  construct  is  suggested  for 
the  representation  of  critical  sections  on  shared 
data  * 

Hoare  imposes  and  formalizes  semantic 

restrictions  on  his  constructs  for  a  clean  handling  of 
shared  data  (only  r  esource  variables  may  for  several 
processes  be  subject  to  changey  and  then  only  in 
critical  sections)  and  gives  proof  rules  for  the 
concurrent  and  the  wi  th— when  statement*  Shared  data 
are  characterized  by  an  assertion  that  has  to  be 
invariant  at  times  when  the  data  are  not  accessed 
(compare  rHoa7  2b])* 

Hoa  rey  C*  A*  R* 

^E22^  of  Correctness  of  Data  Represen ta  ti on _s 
Acta  Informatlca  1  (1972)  y  271—  281 

Hoare  extends  his  axiom  system  for  program 
verification  to  prove  abstract  data  types  correct* 
Essential  arguments: 

a)  A  mapping  has  to  provide  the  relationship  between 
the  specifications  of  the  data  type  'and  its 
1 mpl emen tati on* 


h)  A  correct  implementation  of  an  abstract  data  type 
is  characterized  by 
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[ Hoa741 


I)  an  Invariant  assertion  that  has  to  be  valid 
after  Initialization  between  accesses  of  the 
shared  datat 

II)  the  fact  that  each  operation  defined  on  the 
data  type  has  the  effect  of  its  specification* 


Hoarcf  C*A*1?* 

Mon i  tors ;  An  ^ZSlSS!  Stry:  turl  ng  Concept 

Coinm.  ACM  17,  10  (Oct*  1974),  549-557 

Corrlgendun:  Coma*  ACM  18,  2  (Feb*  1975),  95 


Hoare  introduces  the  aonitor  concept  for  a  clean 
access  of  shared  variables  in  a  concurrent 
environment*  The  monitor  is  an  abstract  data  type 
that  provides 

i)  mutual  exclusive  execution  (short-term  scheduling) 
of  its  operations, 

ii)  primitives  for  the  synchronization  (medium-term 
schedul  Ing)  of  its  accessors  that  may  be  used  In 
any  monitor  operation* 

The  correctness  of  monitors  is  proven  by  Moare's  axiom 
system  for  abstract  data  types  tUoa72b]: 


(  A1  )  '*true**  initial  statement  «im 

(A2)  each  monitor  operation  ”  I  »* 


where  1  is  an  assertion  about  the  monitor  data  that  is 
Invariant  between  accesses,  plus  the  following 
synchronization  axioms: 


(A3)  "T"  cond*wait 

(  A4  )  "lABicond)"  cond*slgnal 


" I aR( cond ) ” 
n  I  H 


for  each  condition  queue  cond  In  the  monitor,  where 
B(cond)  is  the  resumption  condition  for  processes 
delayed  in  cond*  (A3)  and  ( A4 )  ensure  that  the 


monitor  invariant  holds  whenever  the  accessor  of  the 
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[  Roa75] 


monitor  object  changes  by  synchronization* 


Problems:  Too  etrinfient  concurrency  constraints* 


I)  No  Individual  short-term  scheduling  scheme 
for  different  types  of  operations  (e*g;*9 
read  and  write)* 

II)  Monitor  hierarchies  introduce  the  danger  of 
deadl ock* 

ill)  Substructures  of  monitor  data  mast  be 
accessed  mutually  exclusive  with  respect  to 
each  other  <i*e*t  only  one  substructure  may 
be  accessed  at  a  time)* 

iv)  The  synchronization  axioms  do  not  support 
optimal  scheduling* 


Hoaref  C*A*R* 

Par  all e 1  Programming:  An  Ax i oma  tic  Approach 
Computer  Langtiages  If  2  (June  1975)  f  151  —  160 

Hoare  makes  the  first  attempt  to  include  shared 
abstract  data  types  into  the  verification  of  parallel 
processes*  Processes  are  classified  as  follows: 

i)  disjoint  processes  (no  shared  data) 
ii  )  competing  processes  (message  passing) 
lii)  cooperating  processes  (shared  da  tat 

no  synchronization) 

iv)  communicating  processes  (shared  datat 

sync  hr oni z  at i o  n ) 

Proof  rules  for  concurrent  execution  and  restricted 


communication  are  given* 
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[  How76ii  ] 


[ Ho w76b ] 


Hovardf  J«H» 

Provi ng  Monl tora 

Comm*  ACM  19,  5  (May  1976),  273-279 

Exemplification  of  history  variables  in  Monitor  proofs 
(see  entries  [Bri73,  OirGr76b])*  Howard  argues  that 
history  variables  are  essential  to  capture  the 
relationship  between  Independent  proffraM  nodules,  in 
this  case  nonitor  operations* 

For  a  support  of  assertions  that  g^iaran  tee 
optimal  scheduling,  Howard  strengthens  Hoare* s  monitor 
Invariant  (  Hoa74  )  to  imply  non— validity  of  all 
resumption  conditions  in  the  monitor: 

I  £  J aE  =>  -»B(coad)  for  all  dueues  coni 

The  new  axioms  are! 


(  A1  •  ) 
(  A2»  ) 
(  A3»  ) 
(  A4»  ) 


**true"  initial  statement  ”JaE'* 

”JaE”  each  monitor  operation  **JaE” 

"JaE”  cond*wait  **  Ja  B(  cond  I  ** 

'*jAB{cond)”  cond*signal  ”JaE** 


where,  for  convenience,  R(cond)  =>  -icond^empty,  since 
condasignal  acts  on  the  empty  condition  queue  like  a 
null  statement*  The  axiom  system  relies  heavily  on 
the  use  of  auxiliary  variables* 


Howard,  J*H* 

Signal i ng  Mon i tors 

Proc*  2nd  Int*  Conf *  on  Software  Engineering, 

13*— 15* 10* 1976,  San  Francisco,  Cal*,  47—52 

Formulation  of  proof  rules  for  five  signalling 
conventions  in  csonltors: 
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[ HoWl73 ] 


1) 

signal 

and 

wa  It 

11 ) 

s i gnal 

and 

urgent  wait 

ill) 

s ignal 

and 

cont  inue 

iv) 

a  utoma 

t  ic  s 

Ignalling 

V) 

signal 

and 

return 

( 1  )  to 

( 1  V  )  are 

sho  wn 

to  be 

equivalent  in 

the 

sense 

that 

t  hey 

can 

express 

the  same 

c  la  ss 

of 

synchro 

ni  za  ti  on 

prob 

leas  * 

(v) y  the 

poll cy 

of 

Concurrent  Pascal  [Bri75]f  is  strictly  weaker* 

Howard  introduces  a  special  type  of  monitor 
variable  that  plays  the  role  of  a  hidden  proof 
variable  and  internal  ly  keeps  track  of  the  length  of  a 
condition  queue*  The  handling  of  hidden  variables  in 
proof  outlines  is  safer  and  easier  than  that  of 
auxiliary  variables* 


Hoarey  C*A*R*;  Wirthy  N* 

An  Axi  oma  ti  c  DeXlnLiLfiO  S.t.  .Ill® 

Programmi  ng  Language  Pa  seal 

Acta  Inforniatica  2  (1973)  y  335—355 

Although  an  axiomatic  definition 


ianguagey  this  pape 

r  is 

a  good 

correctness  proofs 

in 

many 

al s®>*l  thmi 

The  semantics 

o  f 

the 

common  1 

(  assignment  y  control  structuresy  e 
and  general*  Each  of  them  may 
languagesy  even  with  slightly  dlffere 


of 

a  p 

ar 

t  icu 

1  ar 

ref  e  re 

nc 

e 

for 

c 

langua 

ge 

s* 

an 

guag  e 

f 

eat  u 

res 

tc 

*  )  ar 

e 

cone 

i  se 

apply  for  other 
nt  semantics* 


The  axioms 
formulation  of 


provided  here  can  also 
different  axioms  for 


guide  in  the 
the  language  of 


the  user* 
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[  JaSt77  ] 


[  KaMa75 ] 


[ Kel76] 


(  Laffl77 ] 


f  I.en771 


[  Lip7Sl 


[  Lia77] 


JamaMelt  StiegLert 

Manager s  vs •  M®Qil2£S 

Informa'tlon  Processing  77f  Proc«  of  the 
TFIP  Congressf  8«— 12«8«77t  TorontOf  827—830 

ICatjiy  S«M«f  Manna^  Z# 

A  Close r  Look  at  Te rwinatjon 
Acta  Informatica  5  (1975)  t  333—352 

Kel 1 ery  R*  M« 

Formal  Veri  flea  1 1.  on  of  ParaJj^el^  Programs 
Coram.  ACM  19,  7  (July  1976),  371-384 

Lamport  ,  L. 

Pr ovl ng  Ihe  Correctness  of  Multi process  Prograas 
IEEE  Trans,  on  Soft.  Eng.  SE— 3,  2  (Mar.  1977),  125—143 

Lengauer,  C. 

Str  uktu  ri  er  ter  Betr  iebssys temen'twur f 
mi  t  Concurren  t  Pascal 

HMT— B  236,  Hahn— Mel fner-Tnsti tut  fur 

Ker nf or schung  Berlin  GmbH,  July  1977,  73  p. 

Lipton,  R.J. 

Reduct ion  Z  A  Method  of  Prov i ng 

Pro  pert ie  s  of  Para  1 1 e 1  Programs 

Comm.  ACM  18,  12  (Dec.  1975),  717-721 

Lister,  A. 

The  Problem  of  Nested  Moni t or  Cal  Is 

ACM  Operating  Systems  Review  11,  3  (July  1977),  5—7 
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[  LlZi 75] 


Liskov,  B.H.;  Ziliest  S« H. 

Specif!  catl  on  Technlg^a  for  Da  fa  Abstractions 
IEEE  Trans,  on  Soft.  Eng.  SE-1,  1  (Mar.  1975),  7-19 

The  purpose  of  foraal  specifications  far  data 
abstractions  is  to  describe  the  abstract  object  in  a 
concise,  complete  and  unambiguous  manner  by  a  set  of 
axiomatic  assertions  that  can  be  presuaed  In  proofs  of 
programs  which  use  the  data  abstractions.  That  the 
presuaptions  are  met  by  the  implementation  has  to  be 
shown  In  the  correctness  proof  of  the  module 
representing  the  data  abstraction. 

The  advantages  of  formal  specifications  are 
stressed:  as  a  typical  “problem— o ri en ted”  concept  It 
is  helpful  In  the  design,  i  aplementation,  verification 
and  documentation  of  data  abstractions  and  their 
accessors . 

The  characteristics  of  specifications  of  data 
abstractions  are  illustrated  at  a  stack  specification. 

Different  specification  techniques  are  assessed! 

i)  Use  of  a  fixed  description  discipline 

ii)  Use  of  an  arbitrary  description  discipline 
ill )  Use  of  a  state  machine  model 

iv)  Use  of  axiomatic  descriptions 

v)  Use  of  algebraic  descriptions 

The  assessment  criteria  are: 

i)  Formality  (mathematically  sound  notation) 

ii)  Construct ib il Ity  (support  of  design  process) 
ill)  Compr  ehensibl  it  y  (documentary  effect) 

iv)  Minimality  (conciseness  and  completeness) 

v)  Appl iclabll ity  (for  a  large  class  of  concepts) 
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[  Man7  4 ] 


[  Ha«ra78  ] 


r  OwGr76a 1 


Mannaf  Z« 

Mat  hewa 1 1 ca I  Theory  of  Computa  tion 
McGraw-Hill,  1974,  448  p. 

Manna,  Z»l  Waldingcer, 

The  Log i c  of  Coeguter  Programail ng 

lEFE  Trans,  on  Soft.  Eng.  SE-4,  3  (May  1978),  199-229 

The  paper  gives  an  overview  of  techniques  for  the 
development  and  verification  of  sequential  algorithms. 
As  example  serve  several  implementations  of  the 
gcd  — f  unc  t  i  on.  Four  aspects  are  investigated! 

i)  partial  correctness 

ii)  termination 

iii)  program  transformation  and  optimization 

iv)  program  development 

The  paper  contains  an  extensive  bibliography  and  hints 
for  further  research. 

Owlckif  S.S.;  Cries,  D. 

Axi  oma  tic  Proof  Techni  que  for  Parall  el  P  rogr  ams  !_ 
Acta  Informatlca  6  (1976)  ,  319—340 

Semantic  restrictions  for  the  concurrent  statement  are 
formulated  that  allow  communication  and 

synchronization  between  concurrent  processes  without 
specification  of  shared  variables  in  a  r  esource 
(OwGr76h].  This  language  is  more  powerful  than 

Hoare*s  [ Ho a7 2a ] .  Communication  is  controlled  by  way 
of  an  ^51^1.1.  statement  which  defines  what  Owicki  will 
later  call  an  ^elementary  action”  (Owl77b).  1  ere  it 

is  conditional,  i.e.,  may  include  a  synchronization 
condition.  Syntax! 


P  Uisii  s; 


For  th i s 


c  on  s  t  rue  t  , 


non-interference  is  harder  to 
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express  than  for  the  concurrent  statement  with 
resource  ( Hoa72ay  OwGr76b].  A  set  of  processes  is 
1 n t er f e r enc e— f r ee  iff  there  Is  no  statement  In  anyone 
of  them  that  interferes  with  the  proof  of  the  others, 
l«e«f  whose  execution  changes  assertions  In  the  proof 
of  some  other  process  in  the  set*  The  interference 
argument  has  also  to  cover  termination,  which  can  be 
shown  with  Owickl*s  axiom  system  [Ow3r76b]* 

Owlcki  ariTues  that  the  comparison  of  process 
proofs  rather  than  their  execution  greatly  clarifies 
the  verification  of  concurrent  algorithms*  Her 
standard  proof  policy  is  to  prove  the  partial 
correctness  of  each  concurrent  process,  verify 
non-interference,  and  make  a  termination  argument  for 
the  concurrent  statement* 

COwGr76h]  Owicki,  S*S*;  Grles,  D* 

Ver if yi ng  P  rope  rti e  s  of  Par al le 1  Programs: 

An  Axi oma  ti  c  Approach 

Coram*  ACM  19,  5  (May  1976),  279-285 

Hoare’s  axiom  system  for  the  concurrent  statement  with 
resource  (Hoa72a]  is  relaxed  concerning  the  use  of 
variables  In  assertions  and  extended  by  an  axiom  that 
enables  the  use  of  auxiliary  variabies* 

An  auxiliary  variable  is  defined  as  a  variable  x 
that  appears  in  the  program  only  in  assignment 
statement  of  the  form  x:=E,  where  the  expression  E  may 
contain  any  auxiliary  or  program  variable*  The  axiom 
states  that  an  assertion  which  holds  for  the  program 
including  auxiliary  variables  and  does  not  refer  to 
the  latter,  is  also  valid  for  the  program  without 
auxiliary  variables* 

Mutual  exclusion  and  blocking  In  resp* 

termination  of  concurrent  statements  can  be  proven  by 
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[  Owi77a ] 


looking:  at  specific  expressions  of  assertions  in  the 

parflal  correctness  proofs  of  the  sequential  actions 
in  the  concurrent  statement  and  the  r  esource 
invariant*  Owicki  argcues  that  a  general  method  of 
proving  concurrent  algorithms  correct  has  been  foundf 
whose  appL Ic iabi 1 i ty 9  howeverf  depends  on  the 
synchronization  facilities  in  the  used  programming 
1 anguage* 

Ow  ickif  S*S* 

Speciflcati ons  and  Proofs  for  Abstract 
Da  t  a  Type  s  i n  C  one urren  t  Programs 

Tech*  Rep*  133t  Stanford  Electronics  Laboratories* 

Apr  *  1977  *  2 1  p • 

Owicki  extends  the  verification  of  monitors  to 
Incorporate  the  processes  that  access  them*  4s  link 
between  the  caller  and  the  monitor*  for  verification 
purposes  the  concept  of  a  private  variable  is 
invented* 

-  A  private  variable  is  defined  in  the  monitor*  but 
is  represented  by  a  private  incarnation  for  every 
caller  of  the  monitor  object*  Auxiliary  private 
variables  relate  not  only  the  callers  to  the  monitor 
but  also  to  each  other*  This  enables  statements  about 
the  monitor’s  scheduling  properties  if  one  does  not 
want  to  use  the  restricted  monitor  proof  rules  of 
[How76a*  How76b]* 

The  monitor  is  Incorporated  in  the  concurrent 
statement  as  replacement  of  the  resourc e  declaration* 
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[Owl77b]  Owlcki,  S.S. 

Ver  i  fy  ing  Concuirreip  t  Programs  wi  th  ^ared  Da^a  Classes 
Tech*  Rep*  I47f  Stanford  Electronics  Laboratories! 

Aug*  I977t  20  p* 


Rea 
Owi 
pro 
t  wo 
too 


1 iz i ng  the 
cki  defines 
grammer  to 
statements 
11s  the  sem 


mon  it 
a  ge  ne 
spec  i 
in  1  ts 
aphore 


or  problems  (see  entry  [Hoa74 
ra  1  shared  class  which  allows 
fy  the  exclusion  node  between 
operations*  The  sync hron 1 ra t 
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To  simplify  verification!  the  format  of  shared 
class  operations  is  restricted  to  an  enter?  operate? 
exit  structure!  where  the  atomic  (Owlcki  calls  them 
elementary)  actions  enter  and  exit  only  access  class 
variables  that  aid  synchronization  (so-called  control 
variables)*  The  operate  part  only  accesses  variables 
that  characterize  the  data  object  as  it  is  viewed  from 
the  callers  (so-called  data  variables)* 


Proof  rules  are  given 
Interference  and  calls  betw 
(access  hierarchies)*  In 
monitor  proofs  because  o 
monitors!  turns  out  to 
Practical  hints  for  a  saf 
and  sophisticated  rules  for 
are  given*  Examples  inc 
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On  a  ^Bazzwortt"  Z  Hi  erarchical  Struc  tur  e 

Information  Processins  74f  No*  2  (Software)*  Proc*  of 
the  IFTP  Con^resst  5«  — 10*8«74f  Stockholm*  336-339 

Parnas*  D«L« 

On  t he  Pes^gn  a|^  Development  of  Program  Fara_llies 
IEEE  Trans*  on  Soft*  Eng*  SE— 2*  1  (Mar*  1976)*  1—9 

Si  Iberscha  tz*  A.*;  Kieburtz*  R*B*;  Bernstein*  A*  J  • 
Extend I ng  Cone urr en  t  Pascal  ^o 
All  ow  Dynam  1  c  Resource  Management 

IEEE  Trans*  on  Soft*  Eng.  SE-3*  3  (May  1977)*  2  10-2  17 

An  abstract  data  type  for  the  dynamic  allocation  of 
resources*  the  manager*  is  proposed*  The  approach  is 
implemented  in  the  environment  of  Concurrent  Pascal 
( Br i75] * 

The  idea  is  to  break  up  the  static  access  scheme 
of  the  abstract  data  type  language  in  a  safe  and 
structured  manner*  Processes  state  an  access  right  to 
the  manager  which  incorporates  the  pool  of  allacatable 
resources*  During  program  execution  they  may  request 
resources  from  the  pool*  will  eventually  get  a 
temporary  access  right  (capability)  granted  and 
release  it  after  use* 

The  elements  in  the  pool  are  indistinguishable 
outside  the  manager*  unless  identifications  are  passed 
as  parameter  of  the  manager  procedures*  For  the 
management  of  private  data  objects*  two  standard 
operations*  bind  and  release*  to  be  used  Inside  the 
manager  prevent  multiple  allocation* 
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The  metnager  is  a  solution  to  the  monitor  hierarchy 
problem  (see  entry  tHoa74])  for  two-level  hierarchies* 
Multi-level  hierarchies  remain  problematic* 
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